Proposal for an extended callbacks field

[Etan Reisner]

On Thu, Jul 26, 2007 at 10:15:10PM +0200, Andreas Monitzer wrote:
> On Jul 26, 2007, at 19:38, Etan Reisner wrote:
>
> >>>>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?
>
> when it's done via the discovery browser (see my reply to nwalp in
> this thread).

A discovery browser could just as easily use an account action as it could
a prpl_info callback, so no, using a discovery browser doesn't have
anything to do with this needing to be a prpl_info callback. For that
matter the discover browser could fire a signal to collect disco-actions
in the same way that the buddy list fires an event to get blist entry
actions. So again I ask you what exactly about using a prpl_info struct
solves the needing-to-input a JID problem? Using a discovery browser can,
but a discovery browser does not necessitate a prpl_info callback.

> >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.
>
> Not really. While there's usually one one search service on a given
> server, gateways usually come on groups. For example, my own XMPP
> server on monitzer.com has an AIM and an ICQ gateway. The Openfire
> gateway plugin has gateways for ICQ, AIM, XMPP, IRC, MSN and Yahoo!
> and probably more will be added in later versions.
> One project I have in mind for a later time is writing a gateway
> using libpurple, so I could easily support all the protocols
> libpurple supports, without the trouble of implementing any of them
> myself :)

The dialog could just as easily have a dropdown of all the entries found
as it could have just one entry. So no, the existance of multiple results
doesn't require a prpl_info callback and an Account Action with defaults
populated will work just fine.

<snip>

> >(which pidgin doesn't currently but should get at some point)
>
> Uh, that's news to me. I was specifically told that gateway support
> and a discovery browser would never be implemented and/or accepted in
> libpurple at the start of my project.

Do you have logs of the conversation where you were told this? I don't
recall saying any such thing and I certainly can't imagine anyone else
having said so. What I am certain was said is that pidgin has no interest
in support transports and that pidgin will not write any code to support
them. The discovery browser is something we have been wanting for a while,
I just never sat down to actually work on one because I hate the standard
tree-view UI for them and can't bring myself to write Yet Another
Tree-View UI.

<snip>

> >>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?
>
> Discovery browser.

The question was not about how you are going to have users *find* the JIDs
to perform the actions on but how allowing them to find JIDs *requires*
that a prpl_info callback and how no other method can possibly work for
this. Could you please answer that question if there is in fact such a
restriction.

> andy

Read over my original email and your responses again carefully please, and
notice that you looked at all of my suggestions/questions/etc with the
very assumptions that I was questioning *firmly* in place and then notice
that that tendency is *exactly* what we have been telling you has been a
large part of your problem to date.

I mean no insult, but you aren't helping yourself or us by continuing to
view problems with the narrow tunnel view that your original assumptions
force you into.

	-Etan