[Adium-devl] Java-based libraries... a ponder, a thought, an apology

Sean Egan seanegan at gmail.com
Fri Dec 8 18:58:34 UTC 2006

On 12/8/06, Evan Schoenberg <evan.s at dreskin.net> wrote:
>  A laundry list of deficits would be a good start :)

I (the lead developer of Gaim) can address the ones he's already mentioned.

I think a lot of the confusion comes from that our latest "stable"
release, 1.5.0, does have pretty poor Jabber code; but since branching
for 2.0.0 it's seen a ton of improvements and, contrary to "hasn't
been maintained at all," is actually our best maintained protocol with
two really talented developers and myself all doing regular work on

I represented Gaim (as well as Google) at the XMPP Interoperability
Event in Portland this summer, and I caught a lot of flak from server
developers, some of whom needed Gaim-specific hacks in their code. I
was confused by this (especially since I've seen no bug reports about
it), but then it was pointed out that the 2.0.0 code is actually
really good and it's only the ancient 1.5.0 code that's bad.

We currently depend on libxml2 as our parser, which is better than
many clients. It is true that we used to use the Glib parser which,
among other deficiencies, has no real namespace support. (Loudmouth
also uses the Glib parser, FYI).

It does support a bunch of XEPs. Notable ones off the top of my head:
muc, vcard-based avatars, chat state notification, session
initialization, socks5 bytestreams. Also a bunch of less visible, less
useful ones like jabber:iq:version, jabber:iq:time, etc.

Beyond this, the only XEP ever requested with any regulaity is gateway
interaction, which we refuse to do, because it's totally contrary to
the Gaim model.

I think the main limitation to using Gaim's implementation as the same
limitation to using Gaim's protocol implementations in general.
Because of the way we decided to separate libgaim from any UI, we need
to abstract every IM protocol down to the same thing. Some features of
these protocols lend themselves really well to custom UI, and
decidedly break the mold of our "IM protocol" abstraction. If the
feature is important enough, we think of a way to abstract it and
provide a way to make any UI work with it, but it's for this reason
that we'll often not support particular features unique to any given


More information about the Adium-devl mailing list