Proposal for an extended callbacks field
pidgin at monitzer.com
Wed Jul 25 11:57:57 EDT 2007
On Jul 25, 2007, at 16:46, Etan Reisner wrote:
> As I recall, and I don't recally particularly clearly, you weren't
> 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
> 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
> 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
> 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
* 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
More information about the Devel