Galago

It’s been awhile since I posted anything regarding Galago, so I’m about due for a status update.

SourceForge handed over the galago project to me, so I’ll be getting a site up in the next couple of days, as well as listservs.

Much of the daemon and libgalago library have been fleshed out. I still have some of the querying and signal stuff to do, and automatic merging of people, but it’s getting there fast.

I recently added a couple of new widgets to libgalago-gtk. One displays a list of services that Galago currently knows about, and the other displays a list of accounts that Galago knows about. An account list can be linked to the service list with one API call, and the account list will automatically be updated when the service is changed.

I’m in the process of writing the signal/property watch code now. When that’s done, programs will receive new presences and such as soon as they’re known, instead of querying. I haven’t had this functionality since before the rewrite, so it should be neat to see. As soon as that’s done, work on Evolution integration begins.

Although I took most of spring break off to attempt to relax (something that didn’t end up happening much at all), I’ve managed to make some really good progress with Galago. The library’s API is for the most part stable, and my work as of late has been with the daemon. Most of the functionality is there as well, though some stability issues need solving. I expect to have those issues fixed within a week. Then work begins on Evolution integration, as well as other applications.

The galago project name on SourceForge has been in use for some time, but the project is dead. I filed an abandoned project takeover request earlier this month, and today (well, yesterday now) was the deadline for the maintainers to respond, so we’ll see how that goes.

If all goes well this month with the Galago work, I should have a release out soon. I’ll get a page up before that, with example code, the details behind Galago, a FAQ, etc. Hopefully it’ll clear up some confusion that a few people still have.

I began a rewrite of the Galago framework a few days ago. The original design was good for my initial testing, but I didn’t plan to stick with it. One of the neat things in this rewrite is that unless a feed wants to, it doesn’t have to manually push any presence info. Instead, the code (either via a plugin or the main code of the program) just keeps a couple structs (GalagoAccount, GalagoPerson, GalagoPresence, etc) updated as it does things, and the events automatically propagate.

This has required a number of new considerations when developing this, but I’ve worked out most of them. From an API standpoint, developing an application to work with Galago is really easy now, even easier than before.

The new framework allows for basic identity information, so you can say, “Give me all presence information for Christian Hammond.” Each feed will have a GalagoPerson per each user, which may or may not have a name or other info associated with it. When the daemon receives the presence info, it will get the person info along with that. The people and accounts are stored in a graph in order to determine if accounts are shared anywhere. If so, it can merge the person daemon-side and feed it to any watches or queries.

So, if Gaim sends presence for MyUsername, and Evolution sends a GalagoPerson with some GalagoAccounts for Christian Hammond, and one of the accounts is MyUsername, the daemon will associate them and pass it along. It should work well, barring any unforseen problems.

On a side note, Movable Type is being very strange and only listing one blog entry on the index page. I’m hoping this post bumps it and makes it work again, as it was working just a few days ago. Oh well.

I’ve been toying around with an idea for some time now for a form of emotional presence. The idea being that not only can you tell somebody’s active state, but how they’re feeling. This would conceptually be integrated into instant messengers (although no protocol that I know of supports such a thing currently), and of course Galago would supply the info as well.

So say you decide you want to talk to somebody on your buddy list. Before sending him/her a message, you can check on the buddy’s emotional presence. Then you can make an estimate as to whether or not the person is in a good mood, bad mood, ready to kill someone, contemplating, horny, etc.

The best way to convey such information is by using an eye. The eye is our best way of judging a person’s response, so why not? Smilies could work, but that’s just not good enough. Now, there are a couple of ways to do this. The easiest way is to let the user just set his/her emotional state in the instant messenger like they would an away message. This, like away messages, would just come naturally to some people over time, but others wouldn’t think about it.

Another way of doing it is to have a camera and some face recognition software going that can scan the guy, take a little snapshot, and display it. This is obviously not going to work for everybody, and is a bit more work. This is all just concept stuff right now, though, so implementation is something we can put off just a bit.

I’m sure many of us know people who never use any form of smiley/emoticon during a conversation. They often seem almost machine-like, or perhaps not in a good mood, even if they’re feeling on top of the world. Emotional presence during a conversation could help to fix this. Even if the person showed no emotion in his/her text, the eyes would paint a different picture.

Of course, as someone said, not everyone would want to see a big eyeball on their desktop. Depending on the implementation, this could be changed to text, or a smiley, or hidden altogether.

Oh yeah, and DanielS just put the new Planet Freedesktop.org site up with my new layout. Woo!

I have received several criticisms regarding my design for Galago, most of which I believe to be misunderstandings as to what the eventual goals are. Unfortunately, such misunderstandings and criticisms are now leading to duplicated effort, something which really is not needed.

First off, Galago does require a daemon running in the background, though it’s not something that users are going to have to deal with, so that shouldn’t be a major problem. The main question I have received is, why use a daemon? Why not just have everything listen on the interfaces in D-BUS?

A couple of people have suggested that a daemon is pointless and serves no value. Originally, my design for Galago did not include a daemon. Everything would simply listen on the interfaces and report back. This design proved to be flawed, however. Let me start off with an example.

Say you’re using Gaim to provide feed information, and then you start up a program that uses Galago to receive presence information. Every time you open up a window on this program (let’s pretend it’s something with an address book), the Galago-Gtk widgets are given information on what user’s presence should be monitored. Of course, since it’s just monitoring for new presence updates, it doesn’t have anything currently set. So, each widget makes a query to receive the current presence information.

Now, Gaim had already pushed presence for these users before. As a Galago feed, Gaim is able to push presence when a user’s presence changes, which is quite quick, or it search through the buddy list and build a presence list when specifically polled. The polling is what these widgets have to do to receive initial status. You wouldn’t want to just have them wait with no active presence information until someone signs on/off or sets away.

So, back to our address book. Each widget queries for presence. In a design with no daemon, each feed would receive the poll and send back a response. This could be a lengthy operation, depending on the program feeding presence, or it could be quick. Either way, each feed is going to have to send the presence again.

With a design requiring a daemon, that information has already been pushed and cached. When the widgets in the address book poll for the current presence for a user, the daemon will simply return what it has stored. This is much faster and doesn’t require re-polling every program. It’s also smarter, as it can determine which to poll based on the registration time of a feed (more on that in a second), instead of polling every single program every time.

One person pointed out that you wouldn’t be running Gaim and Kopete at the same time. This, however, is not always true. I know of people who run Gaim and AMSN at the same time, and those who run Kopete and AMSN. Regardless, this particular point wasn’t well thought-out. Not only instant messaging programs provide presence. IRC programs, Gnomemeeting, and other collaboration software.. heck, even a program feeding presence for users logged in to the computer can all provide presence at once. I try not to limit my designs to “what do I need right now, I can always expand it later!” That’s a bad design method, imho.

There are more reasons for the daemon requirements. Feeds will soon be registering themselves when created. It’s something that the developers using the API won’t have to really see or touch. The libraries handle it. Registration simply registers the feed with an ID, descriptive name, and a couple other small pieces of information. This allows the daemon to keep a list of what feeds are available, which can be polled, which can push, their sign-on times and last active times, and actions (sending a message, for instance). Any program can query for a list of applications providing presence, and display them in something like a drop-down protocol box.

Avatars will soon be able to be sent along with presence. This is something else that the daemon can cache, though that may be an option in a preferences file, not that many people would need to modify it. The idea is to have such items expire so that memory is not taken up by unnecessary items. This does require a re-poll from time to time, but it’s considerably less work than polling every feed every time we want to display something.

Finally, Galago is not an instant messaging platform. It is for presence, which instant messaging programs can use or provide if they choose. It is not limited to instant messaging programs either, as I mentioned above. I find it unfortunate that a duplicated effort is going on when the two really should work with each other, but that’s the beauty of open source.

I spent part of the day working on Mono bindings for Galago-Gtk. I now have running a C# version of the Icon Entry test that was in the previous entry. Later, I’ll write bindings for libgalago itself. What’s nice is that this will allow me to prototype much faster. I’m hoping to get someone to do Python bindings. I may handle Ruby myself. Of course, there’s no rush, as the whole system needs to be developed further.

Just a short while ago, Daniel Stone was nice enough to setup a CVS account on freedesktop.org for Galago. It no longer has to run off my slow little CVS server here. I’ll soon get a page up and people can start playing with it.

I’m playing around with the idea of creating a little applet that displays presence info for selected user(s). I don’t know if there would be an icon per person, or one icon with a drop-down. If the later, whichever person is selected on the drop-down will be the new entry on the applet. I’d personally find it useful, and it would be a good little real-world test of Galago.

The past two days, I have been hacking on a new Gtk widget that will be included in libgalago-gtk. It’s a nice little subclass of a GtkEntry that includes an embedded icon, as shown below:

It has a lot of work to go, but so far it’s rather nice.

Avatar development has just begun in libgalago. Avatars, aka Buddy Icons or That Little Picture of Me will be able to be pushed and received just like presence information. This is untested, but should be working by tomorrow, along with a little Gtk widget for easily displaying them.

I think the next trick is to write a general GalagoConnection API that wraps DBusConnection and allows feeds and watches to be registered to it, so that we can eliminate this one connection per feed/watch requirement Galago currently has.

Tonight, most of the work needed for the GalagoWatch was completed. GalagoWatch is a nifty little API for saying, “I want to capture all presence info as it happens,” or “I want to capture all presence info on this service” or “on this account” or “for this user,” etc.

The API is theoretically finished, but not yet tested. I got side-tracked, and adding away status and away message support to the gaim-galago plugin, and am in the process of adding emblem support to the GalagoGtkPresenceIcon widget. Although I should really be asleep right now, I figure I’ll get that done, set the widget up with GalagoWatch support, and get most of the bugs out.

I’m told that jdub’s speech went really well. I’m hoping I can get a copy of it. It’s too bad I couldn’t be there in person to hear it 🙂

I started work today on the first Gtk widget to use Galago. It’s a simple presence indicator icon. It’s a bit hacky, as it polls every 10 seconds for new status, which can make things slower than they should be. However, the GalagoWatch API that’ll be coming in galago soon will deliver new presence and association information directly to anything that uses it, so this problem will go away soon.

Anyhow, I have a test program, and two screenshots. The first is doing a presence query for myself while I’m online and non-idle, and the second is when I’ve become idle:

Perrty.