Galago – Presence for the Linux Desktop

Instant Messaging is becoming ever more pervasive in our lives today. Once upon a time, it was limited to geeks and a minority of our friends, but as we begin to connect with more people, things become much more complex. Christian Hammond explores the more subtle problems of Presence Management.


Nearly everybody today uses an IM client to talk to their friends and family. Some even use it for discussions within their companies. Instant messaging has become an everyday part of life for these people, and have even supplanted the telephone for many uses. Thus we have the concept of Presence.


This article is not about instant messaging, per se, but rather about one key feature that makes instant messengers as useful as they are: Presence. Now, not everybody immediately knows what this is by name, but you’ve definitely made use of it. Presence is essentially the availability status of people. So, in your buddy list, a person’s presence may be that they’re available, away, idle, or marked that they should not be disturbed. These are just a few types of presence.

Presence, as it turns out, is useful even outside of instant messenger clients. Imagine going through your cell phone’s addressbook and being able to determine immediately whether or not someone is on the phone or if their phone is off. While we don’t have that capability on cell phones today, it’s something that you may very well see in the not so distant future. However, we are gaining this functionality in desktop computers. Soon, you will be able to go through your evolution addressbook and, based off information gathered from your IM or teleconferencing clients, you will be able to see who is available and who is not. Incoming e-mails will also provide an indicator, so if you really need to reach somebody immediately, you can choose the IM route over the e-mail one.

It’s all well and good to be able to integrate presence into various applications, but what about setting presence? Right now, when you get up to leave the computer, you have to set yourself away on any and all IM clients and other similar applications that you have running. It can prove to be annoying, and some elect to simply skip the whole process. In time, this will get easier. One single panel applet could set the desired away message on every capable program for you. It could even be intelligent and notice when you’re away from the computer and, depending on the day and time, auto-set the correct away message.

This all sounds great and fun, but someone has to write it. Fortunately, somebody is—me! For the past ten months, I have been developing a project I have named Galago. Galago is a project designed to provide presence to the Linux desktop. It’s a Freedesktop project, and thus is not tied to any particular desktop environment. However, as a GNOME user, I have a particular interest in integrating Galago into the GNOME desktop.

Galago Components

Galago uses D-BUS for communication. D-BUS is an excellent Inter-Process Communication library from Freedesktop. The two main components in Galago are libgalago, the standard library that projects will be working with, and galago-daemon, the D-BUS service daemon that provides the centralized management for presence. Since D-BUS is used, Galago can take advantage of D-BUS activation, so that galago-daemon is always launched when it’s needed. Users simply have to make sure that they have a working D-BUS session bus, and D-BUS takes care of the rest.

On top of those core components, there are other libraries and applications that users and developers may find useful.

libgalago-gtk provides a set of common GTK 2.x widgets for displaying presence information in the form of auto-updating service and presence icons, avatar icons, photo icons, service drop-down boxes, account drop-down boxes, menu items, and more. Once told to monitor an account, service, person, or presence, these widgets will listen in for any changes and update accordingly. This makes the developer’s life a lot easier, especially as the API is simple to use. gaim-galago is a plugin for the Gaim instant messenger client. It pushes service, account, person, avatar, and presence information to galago-daemon by using libgalago any time information on a buddy is updated. Currently, it only works with Gaim 1.0.x. Support for the development branch of Gaim (which will be 2.0.0) is not yet available, due to unfinished changes in that version of Gaim. eds-feed is a tiny daemon that is auto-launched by galago-daemon. Its job is to query Evolution through evolution-data-server and listen in on changes. Any and all person and account information is then sent to galago-daemon. galago-daemon is then able to take this information and better associate various IM accounts to actual people in your addressbook. gnome-presence-applet is an applet for your GNOME panel that allows you to easily monitor a set of peoples’ presences. Though the functionality is quite basic right now, it’s still very handy to those who don’t always want a buddy list on the screen. galago-sharp and galago-gtk-sharp are .NET frameworks that wrap libgalago and libgalago-gtk, respectfully. .NET apps, such as Beagle and perhaps soon Tomboy, can use these to work with the Galago framework in a much more natural way.

The Architecture

As mentioned above, Galago components communicate over D-BUS. However, applications don’t have to know that. Every application, galago-daemon included, talks through calls to libgalago. Or rather, by creating, destroying, and setting properties on objects.

libgalagodefines several key objects to work with: Account, Avatar, Person, Photo, Presence, Service, and Status. The two top-level objects are Service and Person. Everything else lives somewhere inside of them.

Every service, such as AIM, Jabber, or MSN, has a Service object defined. The Service object contains a list of accounts belonging in that service, as well as flags indicating how account names should be normalized (that is, whether they are case sensitive, allow spaces, etc.) for string comparison.

Persons represent an actual person, such as one defined in an address book. They also include properties for various things, such as the person’s first name, last name, address, etc. This is not meant to be a full replacement for the system’s addressbook, so this information should not be relied upon. Persons include one optional photo associated with it, as well as a list of accounts belonging to that person.

Account objects are for IM accounts, GnomeMeeting accounts, etc. An account has an optional avatar and presence associated with it. It has properties for the account’s username and display name, which should always be used in place of the username when being shown to the user. Accounts also contain a list of accounts (or contacts) that can be seen from this account. Think of the contact as a buddy in your account’s buddy list.

  • Photos are images associated with a person that contain a picture of that person, perhaps as defined in the addressbook.
  • Avatars are like photos, except they’re associated with an account and may look like anything. These are also known as “buddy icons.”
  • Presence represents a particular account’s presence information, such as their list of statuses and their idle state and time. Most every account will have a presence associated with it, but not all.
  • Statuses exist inside of a Presence. Each status represents a state, such as “available” or “away,” and may have properties such as an away message associated with it.

The object hierarchy uses a model similar to GLib’s object system, though much simplified. It doesn’t use GLib partially for political reasons with other desktop environments. However, the object system works very much like GLib’s, so developers used to GLib/@Gtk+@ programming will feel very much at home.

Many objects can be marked as being either native or non-native. Native objects are ones that were created by the local application, and non-native objects were retrieved from queries. Most developers will never have to know anything beyond that, aside from a few times in the API where a boolean ‘native’ flag is required.

Clients and Feeds

There are two types of programs that can communicate with Galago: clients and feeds.

Clients connect to galago-daemon through libgalago and query for information. The developer doesn’t have to do anything special to query for information, aside from calling a get function on an object and passing TRUE to the ‘query’ parameter.

Feeds push information to galago-daemon by way of libgalago. They do this by creating instances of objects and setting variables on them. That’s it. Feeds don’t actually have to know that a daemon exists. In fact, even if one didn’t for some reason, the feed would be okay. Due to the object hierarchy provided, applications may find these objects useful regardless, and would just feed to Galago as a side-effect.

Daemon vs. Peer-To-Peer

Many have asked why Galago uses a daemon model, citing that a P2P model would in fact be better. A daemon model allows for all presence, service, account, etc. information to be placed in one single location, making lookups fast. Rather than asking every Galago-enabled application if they have an account with a certain username and then filtering the results, only one query is instead needed. Furthermore, galago-daemon can intelligently combine the information from the objects it knows about and return the most likely correct information. For example, if three applications all claim to know presence for an account, but two claim it’s online while the other claims it’s offline, galago-daemon will assume that the online result is correct.

This is especially important when it comes to Person objects. Every account must exist in a Person, so a Person must always be created. However, in the case of such applications as Gaim, information on the person may not be available. In this common case, an empty Person object would be created. This information needs to somehow be associated with actual person information from an addressbook. galago-daemon achieves this by merging person objects when it determines that a merge is necessary.

Being a D-BUS-enabled daemon, galago-daemon can be auto-activated when first needed. The user doesn’t have to set anything up specifically to launch it or add it to the session manager. This model’s only main downside is that it takes more memory, although not much at all, yet it’s faster, more efficient, and easier to work with.

galago-daemonalso maintains a cache of person IDs. Unlike services or accounts, which have fixed IDs and can therefore be easily referenced, a person in real life does not have any such ID. Names are not unique, and not always provided. So the solution implemented in Galago was to generate a unique ID for the person and store it in a cache, along with a list of its accounts for later reference. Upon startup, galago-daemon makes an internal map of these IDs and retrieves the necessary information when requested later. Applications can then store a person’s ID with some certainty that it will remain available in a future session.

Future Possibilities

Presence on the desktop has a number of exciting future uses. Some will be available soon, due to integration with Galago. Nat Friedman’s Beagle project will be using Galago as a source for some of its indexing. Tomboy may add support in the future as well. Work is currently in progress to bring presence information to the Evolution addressbook and mail component.

One possible future use of presence would be a presence availability scheduler. This would keep track of the presences of people in the background and, when requested, would tell you the best estimate of when a person would be available next. So if you needed to talk to Jim Bob as soon as possible, you could consult the availability scheduler and find out, based on past activity, when Jim is most likely to be available next, and on what service.

Big Brother?

The major concern that has been voiced to me is that this information is really dangerous and that people would be able to start keeping track of people. Well, yes, they would be able to, but it’s no different than it was before. All of the information gathered by Galago is simply what was already available to you. It never leaves your computer, and it’s not put in some massive database. Galago is safe in such a way that 1984 wasn’t. If you don’t want people monitoring your presence, the solution is to not use services where they can do this. The possibilities on the desktop far outweigh the paranoia that will no doubt run rampant.


Presence technology will be a key component in desktop integration in the future. Windows will someday have it, according to some plans at Microsoft. Linux will soon have it by way of Galago. I suspect a number of very creative applications will be developed in the near future that incorporate presence information in new ways. See if you can think of any.

Discuss this story with other readers on the GNOME forums.

Posted on January 10, 2005, in January 2005. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: