Proposal for an extended callbacks field

[Etan Reisner]

This email is likely to be somewhat a duplicate of what Ethan has said,
but I hope to provide some extra explanation/data points/etc. and this
should not be taken as attempting to brow-beat anyone.

On Thu, Jul 26, 2007 at 11:44:10AM +0200, Andreas Monitzer wrote:
> On Jul 26, 2007, at 07:49, Etan Reisner wrote:
> >On Thu, Jul 26, 2007 at 03:44:56AM +0200, Andreas Monitzer wrote:
<snip>
> Yes, I agree. However, even when I discuss the things with you and
> you agree that this callback should be in the prpl struct (just like
> the unregister field), what happens when you encounter this for the
> fifth time?

I am perfectly happy to discuss the merits of making five different things
prpl_info members as each comes up. I would, however, hope that you would
begin to see the system and the logic we use and need to ask us less. Your
current position of not asking at all is a similar application of
reasoning to the problem only from a false premise (that you are never
allowed to touch the struct) which led to a false conclusion (that we are
unreasonable monsters with whom you should never speak).

I have been attempting to correct this unfortunate conclusion for the
entire length of this thread, I hope I have managed to do so.

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

I have suggested (what I consider to be) a better solution twice now, a
solution that mirrors a number of other places in the code where similar
things need to happen. The fact that your current implementation is not
mine is not my fault, nor is it likely yours particularly it was buried in
a long thread both times.

<snip>

> >>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 does using a prpl_info callback prevent you from needing to prompt for
a gateway JID that using an account action does not?

Unless I have missed something drastic, if you need to prompt from an
Account Action you need to prompt from a prpl_info callback. Further,
using the initial server disco response to pre-populate the fields will
work here as a starting point if needed.

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

It doesn't limit you as much if you have a service discovery browser
(which pidgin doesn't currently but should get at some point) and you will
at some point need the ability to input an arbitrary JID so an
enter-a-jid-to-disco dialog will be necessary at some point anyway. Not to
mention the fact that making this a prpl_info callback doesn't magically
solve the "nodes on your contact list and the server you're connected to"
problem. Again, unless I have missed something drastic.

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

Same as above.

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

Same as above. Can you explain to me how making this class of things
members of the prpl_info struct will negate needing to allow people to
enter in JIDs that they may or may not have at hand?

> >The UI for this is an Account Action, I seem to
> >recall you stating at one point that Adium didn't implement the
> >Account
> >Actions, if that is in fact the case then you should check out
> >pidgin and
> >see what they are and how they work.
>
> I already fixed that in Adium. The reason they weren't implemented
> was the lack of support for the fields request API, which I fixed, too.

Good job.

<snip>

> andy

	-Etan