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.

6 thoughts on “Reasons for Galago’s Design

  1. So basicly, the reasons for having a deamon is so that it could cache the information.

    Why can’t the clients cache thier own information and that way send it in a quicker method?

    Another thing, what method is used to communicate between the IM programs and galago, and between the clients and galago?

  2. What’s the difference between querying the presence feeds (Gaim, kopote, etc) over D-Bus and querying the daemon? The widget is querying in both. Are you afraid of flooding the bus or taxing the feeds?

  3. I thought I had answered the question about the feeds rather well. The daemon is queried for caching purposes, as well as other things to come along down the road. This design is not changing.

    I’m making the daemon cache. Not the clients. This is needed because a new widget acting as a client will cause a new poll sent out to all feeds, instead of being able to pull something out of the galago daemon’s cache.

    D-BUS is used for the communication. Also, it shouldn’t be thought of as only “IM programs and galago.” There are possibilities for lots of things to provide presence. IM, IRC, and GnomeMeeting are just a couple of types of possible feeds.

    I should point out that no assumptions should be made based off the code currently in CVS. It is very young, going through many changes, and is not where I plan for it to be yet.

  4. Christian: I think you miss the point. What everyone is wondering is that if you have a daemon you still have to poll information of that, so basically what happens is that it’s cache half way. You still have to send as much data between the daemon and the client as you would have between the IM client and the widget.

    Further more I don’t see why every widget in a program needs to ask the daemon/IM-client if there is another widget in the same program that uses the same data. Just cache it in the client library (you should even if you have a daemon).

  5. “This is needed because a new widget acting as a client will cause a new poll sent out to all feeds, instead of being able to pull something out of the galago daemon’s cache.”

    I think I understand what you are arguing. If there are 3 feeds, and a widget starts up, it has to query all three feeds for prescence instead of just asking 1 daemon. You are saying that you save yourself 2 “asks”. However, this thought relies on a flawed understanding of D-Bus. In fact, this dumbs down D-Bus to a point that there really wouldn’t even be a need for D-Bus.

    “You still have to send as much data between the daemon and the client as you would have between the IM client and the widget.”

    Exactly.

  6. This is the design. I’m sorry you don’t like it, but I’d much rather spend my time writing it than discussing it. So far, I’ve done a damn good job designing my software.

    From now on, please use your real contact information (name and e-mail address) instead of blanks or “me”/”me@me.com”

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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