I’ve been going through several drafts of the status rewrite for Gaim, to make it less AIM-centric as well as core/UI split, and more advanced. The trick is doing this in a way that doesn’t suck. By doesn’t suck, I mean that it’s a clean API that is expandable without being confusing.
Currently, the idea is to have a few main structs:
GaimStatusType – A type of status, containing the account it’s associated with (or probably just the protocol ID), the status type ID, name, parent slot (see GaimStatusSlot below), list of attributes (see GaimStatusAttr below), the primary attribute ID, whether it’s saveable, and whether it’s settable by the user in some fashion.
GaimStatusAttr – An attribute in a status type. It has an ID and a name, and the type of value it has.
GaimStatus – A specific created status, containing the type of status, the associated buddy or account, whether or not it’s active, and a hashtable of filled in values for the attributes in the status type.
GaimStatusSlot – A way of grouping statuses internally. It contains a list of status types, and a flag indicating whether or not the status types inside are all exclusive.
GaimStatusBundle – This is what is created and stored when a user defines their status (which may be an advanced mode in the UI). The status bundle has a name and a list of status IDs that map to it. This is used to, say, set an Away status, but to have it activate “Be Right Back” on MSN and Jabber, a certain away message on AIM. This is of course not something the user is going to have to do. They should be able to set away just like how they currently do.
The trick with GaimStatusBundle is to do things in a way where it supports global status types and protocol-specific ones. Although there really isn’t a distinction… It references by ID. I guess we’d just have to standardize some. I need to think about that more.
It all sounds a bit complex, but it’s pretty easy really. Each protocol plugin registers one or more slots, each with a status type. Each status type can have an attribute. When a user makes a new user-settable status, like an away message, they can build it individually for a specific account or protocol, or globally. It can be as simple as an Away type with an away message (using a standard “away” status type ID and making it global), or they can get complex and set up a scenario like one depicted above.
Status types will be able to go a bit further. Since not all status types are even settable by the user, there can be status types indicating that a user is on a mobile device, that they’re an op in a channel, or whatever. The API for those parts need to be drafted, but once in the base is in place, that shouldn’t be a big deal.
I still have a lot to fledge out. It needs to be slightly complex to be useful, but I think it’ll be manageable.