GObjectification of protocols

[Ankit Vani]

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. Thus
the member 'struct_size' and the PURPLE_PROTOCOL_PLUGIN_HAS_FUNC() macro have
been used.

However, for inheritance, parent types must have a fixed size to maintain binary
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 inherit
PurpleProtocol AND implement PurpleProtocolInterface (and set whichever
functions it implements in the interface). In this case, no padding is necessary
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 struct
from being huge and then you could do a simple PURPLE_IS_BUDDY_ICON_PROVIDER
rather than constantly checking if it has the function pointer. However, adding
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?

                                                                         - Ankit