Proposal for an extended callbacks field
elb at pidgin.im
Wed Jul 25 12:39:51 EDT 2007
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
> 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
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...
Size: 189 bytes
Desc: Digital signature
More information about the Devel