Proposal for an extended callbacks field

[Andreas Monitzer]

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

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.

> 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

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

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.

andy