Reasons for Galago’s Design

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.