Proposal for an extended callbacks field

[Ethan Blanton]

Andreas Monitzer spake unto us the following wisdom:
> On Jul 26, 2007, at 16:11, Nathan Walp wrote:
> > Perhaps you can clarify for me what you would do differently from a  
> > UI perspective?  For flexibility, you need to be able to enter any  
> > JID under the sun.  For usefulness to the average user, you need to  
> > provide a list of JIDs that may be appropriate.  What would your UI  
> > do.  I ask this about register_gateway, as well as user_search.
> 
> I implemented a discovery browser using the raw API. This also seems  
> the cause of my prpl struct-related issues, since I only need those  
> for the discovery browser.
> Generally, I considered implementing the discovery browser into the  
> xmpp plugin. However, I concluded that this is not a useful idea, due  
> to three reasons:
> * When I started the project, I was told that pidgin will never  
> support a discovery browser, due to the non-elegance of the UI for  
> it. This policy seems to have changed about 2h ago, according to Etan.

I would love to know what you were actually told, because I find this
highly unlikely.  I suspect you were told that a *particular
implementation* was not good, not that the feature would never be
accepted.  This sort of statement *cannot* be generalized the way you
persist in generalizing it.

> * The request API is inadequate for this, since such a browser is not  
> a form but a dynamic user interface with a hierarchical list of items  
> that have to be dynamically and asynchronously changed, can contain  
> tooltips, context menus, added/removed and executed. This would mean  
> that I'd have to create a wholly new UI API, which is much more  
> complicated than any that's already there, and it'd be XMPP-specific  
> anyways (and thus would probably not be accepted).

I suspect that one could come up with a general UI form for this;
perhaps some sort of generic tree visualization interface.

> * Sean told me to not bother with implementing stuff into libpurple  
> that requires a tight coupling with the user interface. I can't think  
> of anything with a tighter coupling than this feature.

I don't see why this would have to be tightly coupled; all you have to
model in the prpl is the *data structures*, it's up to the UI how to
deal with them.

It seems like we fight, over and over in this thread, two general
sticking points:

  1) A problem exists, and a *single* particular solution is found for
     it.  Someone says that that particular solution is suboptimal or
     even unacceptable for some reason, and you draw the conclusion
     "the Pidgin developers do not want to solve this problem".  The
     correct conclusion is, "we need to think about good ways to solve
     this problem, the first try wasn't sufficient".

  2) A design principle P, such as "UI and protocol concerns should be
     separate" is held up, and applied to problem X.  When you later
     encounter problem Y, you say "this problem will involve issues
     surrounding principle P, it is unsolvable within
     libpurple/Pidgin".  Again, the correct reaction is "we will have
     to think about how principle P bears on this problem, and make
     sure that we can solve it cleanly".

In both cases, aside from making sure you draw the correct conclusion,
an appropriate course of action is to sketch out the problem in an
email, and send it to devel at .  Note that there are two ways to write
this email, and one will get you better responses than the other; we
have seen, in the past:

   I want to do X, and you clearly won't let me because of principle
   P.  I thought about this for a few minutes and came up with a hack
   that will get it shipping, and I'm sure it's not clean enough for
   libpurple.  I guess we'll just have to agree to disagree.

A more productive email would be:

   I want to do X, and I do not see a way to do it within the existing
   libpurple framework because I have constraint C which makes the
   foo API insufficient for my needs.  I can extend area bar to make
   it work, but that seems dirty.  What can we do to satisfy X without
   violating principle P?

> > On a separate note, more in response to this thread in general:
> >
> > 1. It seems you've been emailing Sean and maybe Etan outside of  
> > this list, which is fine for quick questions.  However, as far as  
> > design descisions go, I'd much rather you ask them on-list, so I  
> > can review the discussion and resulting design, if nothing else.   
> > I've been in the dark about what you've been up to for months
> 
> I'm sorry for that. Those conversations happened on IRC on freenode  
> mostly, esp the ones with Sean. The problem is that a question like  
> "how do I do X in libpurple" usually results in a long discussion  
> about how to design the feature, both on this list and on IRC. This  
> is often the cause that the discussions happen on the wrong medium.

Not only was it on IRC, but it was apparently not in #pidgin.
Conversations on IRC in #pidgin would be perfectly appropriate, and
more developers would be able to keep abreast and stay on top of the
issues.  If they are happening in another public channel (#adium or
whatever, for example), that is fine -- but if you need libpurple
advice or insight, feel free to pop into #pidgin and ask for opinions.

That's not to say that Sean isn't competent to assist, because of
course he is, but it would prevent the rest of us from being so out of
the loop when a big issue like this one comes up.

> > 2. The stated goals of the Summer of Code (unless they've changed  
> > drastically since I last was a mentor) include introducing the  
> > student to the open source community, and educating them about the  
> > open source way of doing things.  I hope that you have looked on  
> > this summer as an excellent opportunity to do just that.
> 
> Yes, I do.
> 
> > You are in a rather special position relative to your peers, in  
> > that you get to work with 2 open source projects simultaneously,
> 
> Two drastically different ones at that...

I don't really think they're as different as you think they are.  You
keep painting Adium as a get-it-done-whatever-the-cost project which
thrives on dirty hacks as long as they make the user happy, but I'm
sure it is in reality much more disciplined than that.  Perhaps that's
not at all what you're trying to say, but that's how the comparisons
keep coming out -- the other possibility is that you think libpurple
is so impossibly rigid that only nuclear-quality code can be admitted
even for an experimental project.

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/9e42299f/attachment.sig>