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