GObjectification of protocols
eion at robbmob.com
Sun Aug 18 15:30:17 EDT 2013
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.
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?
On 19 Aug 2013 06:39, "Ankit Vani" <a at nevitus.org> wrote:
> Hi everyone
> As I understand, a requirement for the protocol API is that it should be
> possible to add new protocol functions without bumping the major version.
> the member 'struct_size' and the PURPLE_PROTOCOL_PLUGIN_HAS_FUNC() macro
> been used.
> However, for inheritance, parent types must have a fixed size to maintain
> compatibility, and a padding of 4 wasn't enough for 2.0.0. Thus my
> original plan
> of using a simple abstract base class for PurpleProtocol does not work out.
> My proposed solution is this. An abstract type PurpleProtocol contains
> data such
> as the id, name, options, user splits, icon spec etc. An interface
> PurpleProtocolInterface is used for protocol functions. Protocols must
> PurpleProtocol AND implement PurpleProtocolInterface (and set whichever
> functions it implements in the interface). In this case, no padding is
> and binary compatibility is maintained without changing the major version
> - if
> core has extra functions, they will be NULL if the plugin uses an old
> version of
> the interface.
> Gary has suggested that instead of using a single interface
> PurpleProtocolInterface which contains all protocol functions, we could
> have a
> bunch of interfaces that the protocol could implement. Then you'd have
> PurpleBuddyIconProviderIface, PurpleAccountSplitProviderIface,
> PurpleStatusProviderIface, PurpleChatProviderIface, etc. It keeps that
> from being huge and then you could do a simple
> rather than constantly checking if it has the function pointer. However,
> a ton of interfaces can be cumbersome.
> What do you think is a better idea - using a single
> PurpleProtocolInterface, or
> a bunch of interfaces for various protocol features?
> Devel mailing list
> Devel at pidgin.im
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel