Proposal for an extended callbacks field

[Sean Egan]

On 7/25/07, Ethan Blanton <elb at pidgin.im> wrote:
> Now, I only followed part of this discussion, but I don't think it is
> at all unreasonable to have a "register an account" callback in the
> protocol structure.  The discussion I remember was about handling
> subsequent callbacks to the initial registration request, which are
> decidedly *not* toplevel protocol actions; however, there may have
> been more to this than I was aware.

Snipping most everything and replying to the thread as a whole:

While some things (e.g. User Tune) are definitely better served by the
Status API than the PRPL struct, most protocol feature will wind up
wanting a spot in the prpl struct.

We have just four reserved spots in that struct, and having done only
2 releases since 2.0.0 we've already determined 2 or 3 features that
want to have their own prpl struct entries.

Something like -vv will likely want several prpl struct entries all to itself.

Whether or not this is an absolutely immediately urgent issue right
now, it is a problem we will definitely need to solve if we want to
expand at all upon protocol features without unecessarily forcing
3.0.0. I'm glad that Andreas is putting thought into the issue.

This hash table proposal is very nice in that it is infinitely
extensible. However, Ethan's point about type safety is a strong one.

Other alternate solutions to this problem that have been brought up in
#adium-devl include:

- Using a linked list instead of a hash table. This, I pretty much
rejected as being worse than the hash table

- using the reserved fields to point to new structs full of reserved
fields. This effectively multiplies the amount of reserved fields we
have, at the cost of unweildly multiple indirections, and along with
it, a stronger possibility for dereferencing NULL pointers ( if
(so-and-so->callback) instead of if (so-and-so && so-and-so->callback)
). This would, however, be more natural for functions that had a lot
of callbacks themselves. Perhaps the prpl would have a pointer to a
VoiceVideoCallbacks struct.

- Expanding the struct, as needed, in prpl.h, and using one of the
reserved values as a version number, or even simpler (and better),
sizeof(PurplePluginProtocolInfo). Then we just do:

if (G_STRUCT_OFFSET(PurplePluginProtocolInfo, callback) <
prpl->struct_size && prpl->callback)
  prpl->callback();

Assuming we keep all those calls to the prpl in a single file,
probably prpl.c, this is probably the cleanest way to extend the
struct.

-s.