Proposal for an extended callbacks field

[Andreas Monitzer]

On Jul 25, 2007, at 18:16, Etan Reisner wrote:

>> 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.
>
> That is a solution, the fact that it wasn't your initial proposal  
> isn't
> the point. The point is that having looked over the requirements it  
> was
> decided that a callback method was not the right one, especially since
> your proposal included passing ui callbacks directly into the prpl.

What's so bad about that? The prpl can't do anything malicious with  
that ui callback pointer.

> In this case I felt like you had over-reacted in that the  
> presentation of
> this issue seemed to be that you had been explicitely barred from ever
> adding anything to the prpl_info struct even when that was  
> obviously the
> right answer.

That's the feeling I got. Additionally, some things Adium needs to be  
exposed from the XMPP plugin will never go into the prpl struct (like  
sending ad-hoc commands, or gateway control), since they're XMPP- 
specific. Right now I just leverage the fact that Adium doesn't use  
the plugin architecture and compiles everything into the library,  
which means that I can call those plugin functions directly. This  
also means that pidgin will never be able to use them (not that you'd  
want to in those particular cases, though).

> Adding a prpl_info callback to unregister an account is *exactly* the
> right thing to do. I support doing that whole-heartedly. I didn't  
> see you
> bring that up anywhere that I look, I don't routinely watch adium  
> bugs had
> you brought it up here I would have immediately supported it.

I didn't try to bring it up, since I considered this endeavor to be a  
waste of my time better spent on enhancing Adium instead (or solving  
the prpl problem altogether).

>> * vv (that one probably needs more than one)
>
> Not brought up anywhere so far, at least not really, unless this is  
> the
> current problem you are running into.

No, this is just something I thought of.

> In which case solving it requires
> the much awaited vv framework to be discussed and implemented, and  
> nothing
> as simple as adding a couple prpl_info structs will really suffice.

Yes I know.

> And no, adding this hashtable wouldn't really allow for libpurple  
> UIs to
> add arbitrary features without needing a pidgin release unless they  
> intend
> to be tracking libpurple from MTN, because libpurple itself will still
> need the code added to actually do things with the added callbacks,  
> and
> those additions will all block on a release, they may only block on a
> minor/micro release as opposed to possibly/occasionally blocking on a
> major release (but that should basically never happen, because that  
> is the
> point of the struct padding). And if the UI is going to be tracking  
> MTN
> then they can maintain any arbitrary changes they want in their  
> libpurple
> build because they won't be able to use the installed version of  
> libpurple
> anyway.

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.

> Long story short: TALK to us when you are trying to figure out how to
> implement something, if it really does need a prpl_info struct  
> change that
> is fine, but when it doesn't accept that and move on

The problem is that I can't just move on and scrap that feature,  
since I'm not on your payroll, but on Adium's. If the Adium project  
wants a certain feature, I have to find a way to get it implemented,  
no matter how (since Adium is very user-driven). Generally, I don't  
like scrapping features just because they don't fit into the current  
design.

> (this is where you tend to over-react by the way, because you  
> assume that your original
> design must be the best and get offended/angry when told otherwise  
> and you
> assume that we are being unreasonable ogres when suggesting you use a
> different method despite our giving reasons for the suggestion).

I'm very much in favor of implementing other people's ideas, if  
they're reasonable and don't require 10x the amount of code than my  
solution. Unfortunately, this hasn't been the case with your  
solutions. Having more code inevitably results in more bugs. In fact,  
the current status-based user tune implementation did create a very  
obscure bug I first had to discover, identify and fix. That alone  
cost me an evening.
My solutions aren't bound to be the best, but they're reasonable most  
of the time (otherwise I wouldn't propose them). If anybody comes up  
with a solution that's easier to implement and thus causes less bugs,  
I'm all for it.

andy