Proposal for an extended callbacks field

[Ethan Blanton]

Andreas Monitzer spake unto us the following wisdom:
> > 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 think you continue to miss our points ... the point Etan and I am
making (and others seem to agree with) is that in several of these
cases, including ad-hoc commands, there are *generic* ways to solve
the problem which do *not* require special-casing the prpl, or any
knowledge in the core that a particular prpl is any different from
others.

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

All right; I will request once more -- what is needed?  If we don't
start getting answers to this question, I think this thread is best to
just die off, and we will accept whatever of your work is acceptable
for libpurple.  I would rather get everything hashed out to the
satisfaction of all parties, but there is a limited amount of energy
available for this.

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

You need to divorce the ideas of "gratuitous version bump" and
"necessary version bump".  Reordering fields just because one can
reorder them introduces a version bump which is wholly avoidable, and
should be avoided.  _Real features_ which require a version bump to be
coherently implemented are a completely different story.

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

I disagree completely with this statement.  The only feature which I
believe was pegged as "not for Pidgin" is transports, and it was
agreed very early on that it is fine if libpurple supports them and
Pidgin simply doesn't use them.

Pidgin does not want to unify all protocols to the same feature set to
the exclusion of real capabilities; nor does it want to treat
everything like AIM (any more).  What we *do* want to do is present
coherent interfaces to all of the protocols, with features which are
somehow equivalent between protocols being accessed through the same
interface; this is the argument we made about "user tune" belonging in
the status API.  I think many of your beliefs that we do not support
particular features or actions, or that we want to steer development
in a particular supoptimal direction, come from the knee-jerk reaction
to any suggestions surrounding your ideas which Etan has previously
mentioned.  We really do want what's best for Pidgin, libpurple, and
Adium *as a set*.  I think most of the friction here is coming from a
lack of dialogue between libpurple, Adium, and your project with
respect to XMPP.  This should be corrected sooner, rather than later,
as we really would like to be able to use your enhancements; since
Adium requires that code is available in a shipping libpurple, I think
it's to Adium's benefit, as well.

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

We don't want to define the user interface.  We may want to encourage
a particular *paradigm*, but that is something entirely different.
The existence and workability of Pidgin, finch, and Adium all tied to
libpurple is proof that we do not wish to define user interface.

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

If Adium's philosophy is "ship at all costs, even if it's crap", then
that is certainly a downside.  I doubt that this is the case.

Ethan

-- 
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/20070726/5fc6bbc7/attachment.sig>