Proposal for an extended callbacks field

[Andreas Monitzer]

On Jul 26, 2007, at 07:28, Etan Reisner wrote:

> What's bad about this is *exactly* the sort of thing that makes  
> Evan cry
> every time we use the request API. Which is that is *assumes* a given
> interface set up, in this case that the core never needs to do  
> anything
> with such information. Unless of course you intend to start passing  
> core
> callbacks in in which case having the prpl call a well-known public  
> core
> function instead of a callback works just as well.

Yes, but the core would still have to call the ui callback as well.  
There has to be a way to pass the function for this ui callback.

> The fact that your currently implemented method is an ugly one (and  
> by the
> way not at all the one I suggested when this first came up which  
> was to
> have a purple_account_registered function and an associated signal

I implemented the one Sean suggested.

> (and possibly a ui_op if needed)

I wasn't allowed to add something there due to the limited amount of  
reserved fields.

> which is simpler and should be able to do the same things as your  
> current method, correct me if it can't) is not a very
> good argument against our assertions that using a prpl_info struct  
> wasn't
> a good idea and is in fact the point I have been trying to make in  
> most of
> these emails. There are any number of ways of implementing the same
> features, the trick is to finding the best one given a large number of
> constraints.

agreed

> Ad-hoc commands are very much something I would like to get pidgin to
> support, but I can not see my way clear to adding them to the  
> prpl_info
> struct because they are inherently protocol specific.

The underlying issue is: Should the prpl struct be the subset of the  
features all protocols support, or should it be the superset of all  
of them?
When using that hashtable, it could be the superset, since not having  
that particular callback in there would not cause any lines of code  
in a prpl. The application would have to special-case the particular  
prpl, but that's the case anyways for special API like ad-hoc commands.

> I can however see
> adding them in a generic fashion as an Account Action (perhaps for  
> actions
> on the server itself) and as blist-node-extended-menu actions for
> individual buddies. Both of which can be added to pidgin in even a  
> micro
> version.

That's already done, but not all that's needed.

>> Maybe my underlying problem is that I'm supposed to implement major
>> features into the XMPP plugin during a 3 months period without
>> resulting in a major version bump.
>
> I didn't see anyone suggest you weren't supposed to require a major
> version bump,

Some folks on this list complained when I changed the JabberStream  
structure's field order right at the beginning of my project, since  
that'd require a major version change.

> Each time I have commented on a proposal you have suggested I have  
> done so
> because I have found them in fact unreasonable given the context  
> they were
> made in. And each time I have endeavored to best understand the  
> impetus
> behind your suggestion and further endeavored to come up with a better
> solution which accomplishes the goal.
>
> You have each time seemed at best grudging and at worst down right
> offended by the suggestions that perhaps your original idea wasn't the
> best one. And on more than one occasion insinuated that we clearly  
> had no
> idea what was going on. Neither of which indicates much towards  
> your being
> "in favor of implementing other people's ideas", I apologize if  
> that was
> your intent and I just failed to see it through all of the rest of the
> stuff.

The problem most of the time was that the libpurple devs didn't  
believe that a certain feature was desired to be implemented at all.  
In fact, the mere proposal of my project is in direct violation of  
the libpurple philosophy, which makes the whole thing very complicated.
The reason is that my project aims to implement XMPP-specific  
features that are unique to the protocol, while libpurple aims to  
unify all protocols to the same feature set (probably rooted in the  
"treat all protocols like AIM" philosophy that was luckly overcome in  
libpurple, unlike in Adium). The action and request APIs can't solve  
all of this.
Another basic issue of me personally is that I don't think that a  
cross platform networking library should define the user interface,  
but that's something I accepted in libpurple to be the root of the  
design concept.

> As to your comments about bugs and metrics and the like, I will  
> once again
> refer to Ethan's comments. An open source project runs differently  
> than a
> commercial one. In a commercial product 'working' is the ultimate  
> goal, in
> an open source one (especially one as prominent as pidgin) the overall
> coherence of the code is at least as important (if not even more
> important) then simply shipping a working product.

This is a major difference between the libpurple and the Adium  
project. Both concepts have their upsides and downsides, and it's  
hard for me to handle this, since I have to work on both simultaneously.

andy