Proposal for an extended callbacks field

[Ethan Blanton]

Andreas Monitzer spake unto us the following wisdom:
> > 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).

There is definitely some tension here; Ad-hoc commands, for example,
are certainly interesting, but are really XMPP-specific.  This means
that they probably don't belong in a global prpl information
structure, as nothing else is likely to be able to use them.  Perusing
the ad-hoc commands XEP briefly, it looks to me like account actions
and the request API are the Right Way to handle this -- that's a first
hit, though, and it may not be correct.

Transports are, of course, an entirely different matter.

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

Learning about good design is certainly not a waste of your time, and
nor is solving things in a sane and supportable fashion.  I'm sorry if
you are being pressured to perform over learning and doing things
right; I would be surprised if this is truly the case, and perhaps you
should have a discussion with your mentor and the other Adium
developers about this.

I get the impression that you believe that the responses to your
suggestions and implementations coming from the Pidgin/libpurple team
have been unreasonable.  I'm sorry that you feel that way, but it
really has not been the case.  Perhaps more buy-in from your mentor,
the Adium team, or interaction with the Pidgin developers would help
ease this apparent friction.

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

So far, I haven't seen any features that would *require* a major
version bump, other than voice and video.  As Etan has requested
numerous times, if you could tell us what you're *trying* to do, we
can help you get it done.

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

Etan never suggested scrapping anything.  When he says "accept that
and move on", he means "accept that the right solution is not a
prpl_info struct field, find a good solution, and move forward with
that new solution".  (Etan, correct me if I'm wrong.)

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

I'm sorry to hear that your implementation of the right solution to a
problem was flawed.  Seriously, though, "I hacked something together
which was really easy but doesn't make sense" is not a good way to
approach development in a codebase which can be complicated and is
used by many developers.  If the right solution to a problem is
difficult at a particular point, remember the old saw about another
layer of indirection.

If something *is* a status, it should be handled as a status.  It's
that simple.

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

"Easier to implement" isn't the only metric, and "bugs in the initial
implementation" is a nearly worthless metric.  Things like "logical",
"consistent", "maintainable", and "correct" are very important.  In
general, if the *only* reasons behind a particular solution are purely
technical, and there are logical arguments for other solutions, some
serious weighing needs to be done -- you are correct that absolute
code size is something to consider, but it can easily be outweighed by
logical consistency.

EEtthaann (I hope I don't presume too much before joining forces)

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070725/3c82a191/attachment.sig>