Proposed attention API

[deckrider]

This is great.  I've had requests for this to be filtered via the
bot-sentry plugin, but there are currently no hooks with which to do
that.

Hopefully it would be like the 'receiving-im-msg' signal so that the
following attributes are available:

Returns:
    TRUE if the message should be canceled, or FALSE otherwise.

Parameters:
    	account 	The account the message was received on.
    	sender 	A pointer to the username of the sender.
    	message 	A pointer to the message that was sent.
    	conv 	The IM conversation.
    	flags 	A pointer to the IM message flags.

On 8/13/07, shellreef at gmail.com <shellreef at gmail.com> wrote:
> I committed a possible "attention" API to im.pidgin.soc.2007.msimprpl,
> in revision
> b888bc5c0494c9dd0398baba81e4d602ac88948f. Here is the commit message,
> explaining what it is all about:
>
>  Proposed "attention" API, a generalization of zaps (MySpaceIM), buzzes
>  (Yahoo), and nudges (MSN).
>
>  Adds a PurpleAttentionType struct to prpl.h, which is used to describe the
>  the attention command (some protocols, notably MySpaceIM, support more than
>  one).
>
>  Uses two reserved fields in PurplePluginProtocolInfo, one function for sending
>  an attention command, another for getting the possible attention commands
>  (similar to status_types).
>
>  Adds serv_got_attention() to server.c, similar to serv_got_im(), used to notify
>  of incoming or outgoing attention notices.
>
> A patch to libpurple is at
> http://msimprpl.darkthoughts.net/attention1.diff . The full patch,
> including all changes to msimprpl to use this new API, is at
> http://msimprpl.darkthoughts.net/attention1-full.diff (these are both
> in the same commit; unfortunately I mistakingly didn't commit each
> separately). The Yahoo and MSN prpls don't currently use the new API.
>
> What does everyone think of these changes?  I think we all can agree
> that a unified attention API is a good thing, but is the way I've done
> it a good way to do it? One thing I'm not sure about is the use of
> reserved fields in PurplePluginProtocolInfo, and how this change would
> impact libpurple's versioning.
>
> If everyone agrees with this change, UI additions to allow using this
> API (discussed in the thread starting here:
> http://pidgin.im/pipermail/devel/2007-August/002468.html) would be the
> next logical step.
>
> Regards,
> -Jeff
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>


-- 
ASCII ribbon campaign:
()  against HTML email
/\  against Microsoft attachments
    Information:  http://www.expita.com/nomime.html