Proposal for an extended callbacks field

[Andreas Monitzer]

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

> 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 :)

> It doesn't limit you as much if you have a service discovery browser

It wouldn't limit at all in that case. That's what Adium does right now.

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

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

Yes, that's integrated into the discovery browser.

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

andy