Re{factor,write} of status API

John Bailey rekkanoryo at
Tue Jun 28 20:31:59 EDT 2011

On 06/27/2011 11:08 PM, Paul Aurich wrote:
> I'm assuming everyone would be open to rewriting/simplifying it for 3.0.0.

If not, we should kick out the offenders! :-P

> 1) What things do you want to keep?

As little as possible.  The ability to have attributes like the itms URL on AIM
or the mood, tune, etc. stuff on XMPP would be nice, and would certainly cause
some whining if we dropped support for attributes.

> 2) What things do you want to lose (other than as large a percentage of the
> exposed API as we can)?

PurplePresence.  See my response to Jan.

> Regarding #3, one thing I'd like to see is a single (exclusive)
> "PurpleStatus" per buddy/account.  Each time the status changes, a new
> PurpleStatus should be instantiated; this way, status-changed events have
> both a "old_status" and "new_status" object, which aren't the *same stupid
> object* (see #4696).

Again, see my response to Jan.

> Furthermore, I don't think we *really* need to keep the "default" values
> for each status (these are used when changing status to reset all the
> unspecified attributes to their default values) allocated once per buddy
> (surely once per account is good enough?).  I'll caveat the prior sentence
> by saying that I *think* it's correct these are stored per-account, but I
> can't actually reverse engineer the hackery I did for the XMPP prio plugin
> (
> a few years back.

Why couldn't we just have something like purple_status_set_defaults(PurpleStatus
*, PurpleAccount *) to do this for us on the fly?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Devel mailing list