Proposal for an extended callbacks field

[Ethan Blanton]

Sean Egan spake unto us the following wisdom:
> 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.

That's fine.

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

Absolutely.

> 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.

I'm not sure that a) this is a real problem, or that b) we should
worry about it.  If we need a 3.0, we need a 3.0.  "We might want that
padding for something else" is NOT a good reason to avoid using the
padding.  Careful consideration of whether something belongs in
prpl_info or not is fine (in fact, if there were ever enough time, we
would probably want to go back and *re*consider some stuff that's
there now), and we should encourage the same consideration of
modification of other structures -- not because the space in them is
valuable, but because we should strive for rational and orthogonal
features, packaged in a way that makes them accessible for varying
implementations both in the UI and on the protocol.

> - 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.

Note that this is what whiteboarding does, as well as perhaps other
features in other places.

> - 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.

This seems OK to me, but I think all of it is overkill.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://pidgin.im/pipermail/devel/attachments/20070725/df4d1212/attachment.pgp