<p dir="ltr">If you split into multiple smaller interfaces, you'll still need to check for specific functions as not all of them might be provided for an interface, eg not all chat features might be able to be implemented. </p>

<p dir="ltr">Is it possible to set the function pointers using a similar system as you have for the plugin information (with the key-value pairs), or does that not good form in a gobject system? </p>
<p dir="ltr">Cheers, <br>
Eion </p>
<div class="gmail_quote">On 19 Aug 2013 06:39, "Ankit Vani" <<a href="mailto:a@nevitus.org">a@nevitus.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone<br>
<br>
As I understand, a requirement for the protocol API is that it should be<br>
possible to add new protocol functions without bumping the major version. Thus<br>
the member 'struct_size' and the PURPLE_PROTOCOL_PLUGIN_HAS_FUNC() macro have<br>
been used.<br>
<br>
However, for inheritance, parent types must have a fixed size to maintain binary<br>
compatibility, and a padding of 4 wasn't enough for 2.0.0. Thus my original plan<br>
of using a simple abstract base class for PurpleProtocol does not work out.<br>
<br>
My proposed solution is this. An abstract type PurpleProtocol contains data such<br>
as the id, name, options, user splits, icon spec etc. An interface<br>
PurpleProtocolInterface is used for protocol functions. Protocols must inherit<br>
PurpleProtocol AND implement PurpleProtocolInterface (and set whichever<br>
functions it implements in the interface). In this case, no padding is necessary<br>
and binary compatibility is maintained without changing the major version - if<br>
core has extra functions, they will be NULL if the plugin uses an old version of<br>
the interface.<br>
<br>
Gary has suggested that instead of using a single interface<br>
PurpleProtocolInterface which contains all protocol functions, we could have a<br>
bunch of interfaces that the protocol could implement. Then you'd have<br>
PurpleBuddyIconProviderIface, PurpleAccountSplitProviderIface,<br>
PurpleStatusProviderIface, PurpleChatProviderIface, etc. It keeps that struct<br>
from being huge and then you could do a simple PURPLE_IS_BUDDY_ICON_PROVIDER<br>
rather than constantly checking if it has the function pointer. However, adding<br>
a ton of interfaces can be cumbersome.<br>
<br>
What do you think is a better idea - using a single PurpleProtocolInterface, or<br>
a bunch of interfaces for various protocol features?<br>
<br>
                                                                         - Ankit<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@pidgin.im">Devel@pidgin.im</a><br>
<a href="http://pidgin.im/cgi-bin/mailman/listinfo/devel" target="_blank">http://pidgin.im/cgi-bin/mailman/listinfo/devel</a><br>
</blockquote></div>