[Adium-devl] Some AIAccount improvements

[Colin Barrett]

On Jan 22, 2007, at 4:02 AM, Evan Schoenberg wrote:

>
> On Jan 22, 2007, at 5:35 AM, Colin Barrett wrote:
>
>> - It would be nice to know if sending an autoreply is supported
>> natively by the service, mostly so the autoreply plugin can append
>> (Autoreply) or some other flag on MSN or other protocols that don't
>> natively support autoreplies.
>
> That's a good idea.  The accountside method for Gaim is already  
> implemented, in CBGaimAccount... the name is dumb, though, and it  
> obviously needs to have a stub in the superclass before it can be  
> used generally.
>
> // **XXX** Not used at present. Do we want to?
> - (BOOL)shouldSendAutoresponsesWhileAway
> {
> 	if (account && account->gc) {
> 		return (account->gc->flags & GAIM_CONNECTION_AUTO_RESP);
> 	}
> 	
> 	return NO;
> }
>

That's an awfully strange method name. I was thinking

- (BOOL)supportsAutoreplies;

Since the flag on AIContentMessage is autoreply:.

>> - It would also be nice to know if a protocol generally handles
>> actions (/me) at the protocol level. We'll need this when/if we do
>> IRC, and on GTalk it would be nice to implement this, since the
>> official client handles /me's. There may or may not be a XEP for  
>> this,
>> but we'll still need to have a way to expose this property to the /me
>> plugin.
> I think it'd be nice to have the method be a query for a particular  
> action... so if a protocol handled "/join" but not "/me" we'd know  
> what to do in both cases.  Right now there's some slightly awkward  
> code in place in the gaim plugin which checks this after a message  
> is sent so that we can have better handling of it than the gaim way,  
> which is hardcoded to throw an error if you type an action which  
> isn't supported... which strikes me as really silly because if I'm  
> an AIM user and would never think that /join should be a command I  
> would be definitely annoyed to find I simply can't send that because  
> "That action is not supported on this protocol."

That would be good. Peter's suggestion is a fine implementation. Do  
other protocols support other actions natively? We got rid of / 
scriptname as a script handler, right?

-Colin