Proposal for an extended callbacks field

[Ethan Blanton]

Andreas Monitzer spake unto us the following wisdom:
> >> The functions that are already implemented and have to be used from
> >> the application but are not in the prpl struct right now are:
> >>
> >> purple_account_set_register_callback
> >
> > As I said in my previous email this isn't a prpl_info member and does
> > not need to be
> 
> As I already said in the email you replied to, I didn't imply that  
> this belongs to the prpl struct, just that a better solution should  
> be found when you want to have a clean API.

We completely agree.  We didn't propose, and do not support, the
unclean solution which you chose.  You cannot hold it up as something
which is somehow our fault, as you have done several times in this
thread.  If *you* choose a solution which is poor, and *you* implement
a solution which is poor, without appropriate consultation with us,
then you reap what you sow and we'll see whether we can make it
something palatable come inclusion time.  This comes back to the value
of dialogue.

> > having the prpl call known functions in the core which then handle
> > calling ui_ops and/or emitting signals is a perfectly good way to
> > handle this and lets any ui or plugin handle it however they want to.
> 
> Yes, but the application still has to supply the callback in some way.
> 
> >> jabber_register_gateway
> >
> > Account Action
> 
> You'd have to prompt for the gateway JID, which is a very bad UI (how  
> should the user know what to enter there?).

How are you handling this?  If you can handle it gracefullly with a
prpl_info field, you should be able to handle it as an account action;
explain the constraints, here, and we'll try to find an equitable
solution.

> >> jabber_adhoc_execute
> >
> > Account Action and blist-node-extended-menu action for most things, 
> > if we need a service discovery browser or an enter-a-jid-to-disco
> > action those can come later and likely be done with the existing
> > mechanisms.
> 
> Yes, as I already said, those are already done, but not all what's  
> needed, since that limits you to nodes on your contact list and the  
> server you're connected to.

I don't understand this at all.  This, and the previous point, seem to
be symptoms of what got us into this noncommunication mess to begin
with; you come up with a particular implementation, make a whole
raftload of (possibly unnecessary) assumptions, and then apply them to
all of our suggestions, which have not made such assumptions.  This
smacks loudly of the user_tune prpl callback idea, to me.  There is no
reason that a prpl callback could get around this supposed limitation
of nodes on your callback list and the server you're connected to, but
an account action could not.  Why can the account action not trigger
some sort of browser?

> >> jabber_ping_jid
> >
> > Account Action and/or blist-node-extended-menu action.
> 
> Same as above.

And, same as above.  How is this limiting?  Please explain the
assumptions you are making, so we can determine if we're missing
something, or if there are assumptions which can be lifted.

> >> jabber_user_search
> >
> > User search already exists for XMPP or do you mean something other 
> > than the JUD based searching?
> 
> This action prompts the user for the JID of the search service, which  
> has the same issue as the gateway registration you're proposing: How  
> the heck should the user know what to enter there?
> Right now you're prefilling the field with the search service of the  
> local server, which is a nice pick, but not the only one possible by  
> far.

How do you plan to solve this as a prpl op?

> I think back then I proposed adding the registration callback to  
> struct _PurpleAccountUiOps, which still looks like an obvious choice  
> to me...

For the record, I think you were encountering more resistance to using
reserved fields than you should have; however, since this discussion
was never public with the purple team, we never got a chance to
discuss it.

> > Yes, this certainly sounds like the status api could use fixing up. At
> > first blush it would seem that adding a GList of changed status keys
> > would do what was necessary for this circumstance, it would simplify
> > the do-I-care check immensely.
> 
> Yes, agreed. That solution would probably be easy enough. The problem  
> is that this is certainly a 3.0 change, so I guess it's too early for  
> it.

Not at all; there's no reason a new access function cannot be written,
with the old one simply calling the newer, more flexible function with
default fields.  We have done this in numerous places in the past, to
preserve backward compatability and provide forward feature
enhancements.

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/2f5f644f/attachment.sig>