Proposal for an extended callbacks field

[Ethan Blanton]

Andreas Monitzer spake unto us the following wisdom:
> On Jul 25, 2007, at 16:46, Etan Reisner wrote:
> > As I recall, and I don't recally particularly clearly, you weren't 
> > allowed to add what we considered a frivolous prpl_info callback, that
> > is one that could be solved in other ways we considered more useful.
> > There is a huge distinction between not being allowed to do something
> > at one point and not being allowed to it at all.
> 
> The first occurrence was the user tune information, which is now  
> solved using the user status, requiring a bad hack in the XMPP code  
> (since not the whole status information is sent via <presence/>  
> stanzas any more, and thus some status changes don't require pushing  
> the <presence/> stanza to the server).

Yeah, this is indeed a problem with our status handling, as it is
obvious that there are circumstances when only partial status changes
are warranted.  Now, I haven't looked closely at the status API to see
if there's a way to handle this without some extra information (and,
by the way, keeping some information in the prpl is not at all a "bad
hack" -- it's *far* more clean than, for example, a hash table of
untyped callbacks :-P), but if there isn't, such a mechanism is
probably warranted going forward.

> OT: This could be solved by not having a callback for setting the  
> whole status, but for changing specific fields of the status. So you  
> could have one callback for the field x, y and z, and another one for  
> the status fields a, b and c.

Or a callback which receives a set of fields and their new values,
rather than a whole pile of callbacks.  One could, of course, use this
to break out into individual callbacks if that was really desired.

> The second occurrence was the registration callback. This wasn't  
> solved, but a workaround was introduced by having an out-of-struct  
> function for it.

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.

> > I don't know why it is that you seem to keep over-reacting to the 
> > comments that come from the pidgin side of things but you really need
> > to stop it.
> 
> I don't feel like I'm over-reacting (I'm not saying that I didn't do  
> that in the past). Sean told me to avoid changes to the prpl struct  
> at all costs (even sacrificing having a clean API or readability), so  
> I proposed a solution to this issue. This is not a rant, but a  
> rational way of proceeding when there are problems that hinder  
> development. There were multiple cases where I answered to feature  
> requests "I can't do that, because it'd require another function in  
> the prpl struct". The most recent one that triggered this proposal  
> was http://trac.adiumx.com/ticket/7326

Register/Unregister seems like a reasonable protocol callback pair to
me.  I see no reason why we should resist using reserved functions for
this.  It might (or might not) make sense to have a single callback
with a register vs. unregister differentiation option.

> > So again I ask, what exactly is the problem that you are running into
> > now that requires a prpl_info callback?
> 
> The ones I can I think of right now are:
> 
> * setting a register callback
> * unregistration
> * vv (that one probably needs more than one)

Voice and video will almost certainly require something other than a
callback or two.  At the very least, some sort of supported features
flags (or whatever interface, you understand the picture) will be
required.  Furthermore, I think some general rethinking will be called
for here; I wouldn't lump this in with "things which simply need a
callback".

> The point is though, that this list can be extended indefinitely. I'm  
> not the only one who wants to add features to some prpl I guess.
> Of course, in regular libraries, big features like vv would only be  
> introduced in major version jumps, but since libpurple versioning is  
> limited by the pidgin release cycle, the option of having major new  
> features in minor versions would help tremendously. This would allow  
> IM clients' devs other than pidgin's to implement those features into  
> their libpurple-using clients without having to wait for the next  
> pidgin release.

If libpurple needs to be divorced from pidgin versioning at some
point, then let's discuss that.  I haven't seen anything, yet, which
leads me to believe that it does.

I don't think that a few weeks to a month between releases is holding
anybody up, particularly.  It may seem like it on a given day, but in
the big picture, I doubt it.  The versioning issue is separate from
release cycles.

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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070725/b8de134a/attachment.sig>