Proposal for an extended callbacks field

[Andreas Monitzer]

On Jul 26, 2007, at 07:49, Etan Reisner wrote:

> On Thu, Jul 26, 2007 at 03:44:56AM +0200, Andreas Monitzer wrote:
>
> It had no chance of becoming anything but annoying since you didn't  
> bring
> it up when you ran into it except that very first time. As I've said
> before, discussing things is almost always better than not discussing
> them. Especially when you think you weren't understood clearly the  
> first
> time or that the original decision was the wrong one.

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?

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

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

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

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

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.

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

>> Note that the first one should probably be replaced by a registration
>> callback in the _PurpleAccountUiOps struct (so you don't have to
>> define a callback in addition to defining this struct). Sean
>> suggested the current solution, since he didn't want to use up one of
>> those four reserved spots on the struct.
>
> Given the above suggestions of using Account Actions (is there a  
> reason
> that doesn't work), and my suggested purple_account_registered  
> function
> none of the above requires any prpl_info changes. Can you see why  
> we don't
> immediately jump on the idea that everything needs to go into the
> prpl_info struct? Is there some reason my suggestions about don't  
> work?

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

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

andy