Old Stuff

A lot of good presence work was done on Galago today. Presence feeds can now return a list of presences for the user sent to it, which is useful on such things as IM. Say, for example, a program requests presence for user ChipX86, but neglects to specify a service or source account, since it just doesn’t care. The feeds can now return lists of presences, containing, say, Yahoo and AIM presences.

So I got tired of playing with a test presence feed, and wrote a plugin for Gaim that would provide presence information. So far, it’s working rather well, except for the fact that Gaim’s current concept of status royally sucks. I’m working on it, but am having difficulties creating an easy to use API that handles status exclusion. I talked to Kevin Stange, and he suggested using slots, which could work.

So, with that concept, protocol plugins would define one or more slots, each with an exclusion boolean flag set to TRUE or FALSE. Status types would be registered into a slot. The typical status types, such as Offline, Online/Available, Away, Extended Away, etc. would all go into an exclusive slot, while status types such as Mobile, would go into a non-exclusive slot.

The idea is to have this covering all aspects of status. The state of the user, what the user is connecting from (cell phone, etc.), and anything else. Not everything would have to be displayed. There will be type hints used for that, and prpls can still specify what to show. However, there will be a lot more flexibility in what kind of states can be chosen. Available messages will be doable for protocols that support them, for example.

Also, this will be core/UI split, which has been needed for awhile.

I should have status done within the month, if all goes well.

Depending on what happens tomorrow with my girlfriend, I may or may not start the galago-gtk widgets module in CVS. If I get something really cool, I’ll post a screenshot.

So far, the Galago framework is coming together rather well. I don’t have anything that runs and communicates yet, but a lot of the base framework has come together, and I expect to build test programs by next week (assuming all the other busy things in my life don’t take up too much time).

At the moment, I’m working on the Galago Presence stuff. I’m running into design problems that I also have with Gaim’s status rewrite. This is to be expected, since the two are essentially the same thing.

The main issue I had in the Gaim status rewrite is that I wanted to generalize status types, and provide a mechanism for multiple types to be set at once. This also requires that some times exclude other types from being defined. Unfortunately, this creates a big mess when registering status types.

My vision for Gaim status is to cover all aspects of a user’s status. Their online state, offline, away, brb, idle, whether they have encryption enabled, mobile communications, etc. The display in Gaim would be the same as it is now, with the exception that the Away menu would be a little different, as would the away dialog. Icons would still appear in the list.

The problem comes when we want to say, “away implies online” or “online excludes offline” or “I’m online, away, but hidden.” It can get confusing, so it needs to be done in a simple fashion.

Now, back to Galago and status. How detailed should status information be? We probably don’t need to know every little detail like we do in Gaim, but maybe we do? How do we standardize it then? It’s easier when we have control over the source tree in Gaim and can make status IDs all match, but when we have third party applications defining their own IDs, it doesn’t work so well.

The approach I’ve taken in the Galago presence code currently is to separate it out into a status type (an enum defining OFFLINE, AVAILABLE, AWAY, EXTENDED_AWAY, and HIDDEN, currently), a status name (“BRB,” “On The Phone,” “Away,” “Online,” etc.), and an optional message (such as an away message). I believe this is sufficient for most purposes. It won’t allow the applications using Galago to display a mobile or game indicator or other such things, but it will give the generic status to those applications.

Another option is to do what we have above, but allow a person to have multiple statuses. That way, they can indicate they are away and are using a mobile device. This should be broadcasted as one presence packet, as presences for a single person on one protocol are not additive. The last one sent is the one that gets seen.

There’s still an issue with applications sending odd statuses, like the user is away and available at the same time, or they’re offline and online. I guess that’s up to the individual programs to fix. We can’t do all their work for them.

It’s still not as flexible as what Gaim’s status model will end up being, I’m sure, but it works sufficiently for most cases, in my opinion. If the user wants any further information on the user’s status, they can check their buddy list or whatever else is providing the detail.

With that in mind, I’ll probably move forward in that direction.