Integrating IM applications - OFI

[Christian Hammond]

On Thu, Jan 13, 2005 at 05:02:58PM +0100, Igor Popik wrote:
> We are aware of Galago project. But in our opinion such integration 
> should be done in ligth-weight manner :-)

This is then a misunderstanding of the workings of Galago, and the
reasons for its design. Many of the issues I had to address are ones
that you will find yourself addressing as well. At such a point, I
imagine someone else will come along and say yours is no longer
light-weight ;)

Galago is not complex. It's done over D-BUS with a fairly simple set
of APIs. It has a convenience library which I advise projects to use,
simply because there's no reason to duplicate code and bugs.

The architecture is basic. You have a centralized service run by
galago-daemon (yes, there is a reason for that, which I will get to in
a second). Applications register themselves with the daemon, either as
a client or as a feed. Feeds are just clients that can also send new
presence info.

The basic components in Galago are the following:

Persons - They represent an actual person, and can optionally have
contact info. The reason for the Person's existence is so that one can
say, "What is the status for Joe?" and get it, no matter what
services/devices Joe is on.

Services - IM services, VoIP services, etc. Pretty straight-forward.

Accounts - Accounts belonging to a person. Also pretty
straight-forward and necessary for this kind of work.

Presences - And here's the core of it all. The presence shows the
account's idle state and time, their statuses ("away," "online,"
etc.), and other info.

So far, I don't think we're unnecessarily complex.

Now, what people often think is complex is the fact that we have a
daemon. I believe people think it's complex because they haven't
thought through the requirements that far enough, and I believe they
dislike daemons because right now, it's popular to dislike them.

If you have multiple clients broadcasting information on a person,
account, service, or presence, you need a way to combine them. You
also need a way to query for such information. The daemon solves all
of that. Sure, an application can broadcast to every other application
requesting the name of an account, but then it has to handle its own
merging or deciding which to listen to. Why do that when it's already
done for you?

galago-daemon on this box only takes a few megabytes of RAM. Usually
4MB here. And that's with a very full gaim buddy list, Evolution, and
some utility apps all running, 24/7. So it's not a memory hog.

How about speed? Well, we already save on the broadcasting and merging of
info on a per-app basis, since the daemon is doing this for us. So I
think we're winning there.

Stability? If the daemon goes down, D-BUS will bring it back up the
next time, and no info will be lost.

How about persistence? This is actually important with Persons. You
can't be sure of a Person's name, because nothing may provide it. You
need some form of UUID. We cache those and cache the info assigned to
it, so an app can always reference a person and never worry about
whether or not it'll be able to retrieve that information.

How about evil? Daemons are evil, right? Well, no, they're actually
not that evil. And D-BUS service daemons auto-launch when needed, so
that's not another line in an init script or session manager.

Where is it complex? It's light-weight enough from a protocol
standpoint, I believe. It does exactly what it should without trying
to do too much. It's not an IM service, though with the Action support
I'm writing for the next release, it easily could do that without
bloating too much. However, I was considering a separate IM D-BUS
spec that piggy-backed on Galago. Save some work, you know? Modularize
things.

Right now, Galago's becoming a bit more popular. Beagle is using it.
There's gaim support. A number of developers have started hacking on
Galago-enabled applications. Evolution will get support in time.

I looked at the README you provided. It does seem very light-weight,
with only a few commands. What's going to happen when people decide
that's not enough? How complex will you need to make that to support
the forms of chat that MSN have as well as the forms that AIM has?
What about extra info attached to statuses, such as away messages?
Protocols that support only one status at a time? How about the ones
that support multiple statuses? Or formatting for IMs? Buddy
icons/avatars? Transports? Error handling? I work on Gaim as well as
Galago, and creating such a solution isn't as easy as it first may
seem. There's a lot of complex abstraction that takes place, and these
problems must be thought through well in advance if the architecture
is to stay clean.

I think a generic IM interface on D-BUS is good. Perhaps doing
something that doesn't try to replace an already well used API would
be more beneficial to both parties, though. I wouldn't mind helping
out on something like that.

Sorry to cut this short, but I'm late for work.

Christian

-- 
Christian Hammond         <>  The Galago Project
chipx86 at gnupdate.org      <>  http://galago.sourceforge.net/
   Don't compare floating point numbers solely for equality.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050114/5e46197a/attachment.pgp