More on Jabber non-adoption

Jabber frustrates me a great deal, mainly because I think it should be doing a lot better and acting more coherently than it currently does. The decentralised nature of the system itself seems to have persisted into development efforts (i.e. there are eight different open-source Jabber server implementations, and another six commercial implementations; that’s fourteen different server implementations. You can tell it’s too many because in the “Feature Score” column on that list, not one of them scores 100% and the highest score for an open source server is 79%).

The clients, as I’ve discussed before, are in an even worse state.

The_Tick discusses some of these issues and more in his latest blog post “Some of the reasons that jabber isn’t where it should be“.

My problem, of course, is that I’ve got a big mouth, and not much to back it up with (my main dev. language is Java, and all of the Java clients are comparatively immature). So, OK, what can a frustrated developer do to help things along? First thing – don’t start a new client. Next, look at the state of the current clients and see what you can do there. So OK, let’s look at jabber.org’s list of recommended clients for Windows:

  • Exodus – open source, Delphi
  • Gush – closed source
  • JAJC – closed source, possibly dead
  • Pandion, open source, nasty disconnection bug
  • Psi – open source, C++, QT
  • Trillian, closed source

So OK, realistically you’re now down to contributing to Exodus and Psi (or fixing Pandion’s disconnection bug, which doesn’t look like an easy task).

Until recently, even looking at the source for Psi was pointless because it depends on QT, which hasn’t been available (for free) on Windows. Trolltech recently announced that starting with QT4, QT will be available for open-source development on Windows for free (see what the Psi forums had to say). This is great news, because Psi is my favourite client; but on the other hand Psi used to advertise itself as the Jabber client for power users (they don’t do this any more), and whilst they’re now doing massive work on usability and the development community is very active (they have leadership and focus, I think the Psi community is very impressive) I think it’s likely to stay fairly focussed on power users.

Personally, I’ve always found Exodus pretty hard going, but it *is* in Delphi, which I can write, and it looks as though it should pretty simple to make a number of improvements to the UI without too much hard work, but I don’t have a copy of Delphi 7, which it appears to be written in, and which no longer seems to be available from Borland. Which would be a problem.

So, given that I’m lazy, this leaves me doing one of the following:

  1. buying (or, er, “obtaining”) Delphi and hacking on Exodus
  2. searching for another client with equally good JEP support to hack on
  3. spending my life unconstructively complaining on my blog, frustrating all and sundry

but seeing as I hate both whiners and hypocrites I’ll aim for the first πŸ™‚

Published by

7 thoughts on “More on Jabber non-adoption”

  1. hey Phil,

    as i saw you on the JBother forum as a member today and since your ‘main dev. language is Java’ why not take a closer look at JBother and help develop it? πŸ™‚

    it’s surely promising and is actively developped.

    cheers,

    Stellaris

  2. Hi Stellaris, good spotting πŸ™‚

    I think JBother has potential, especially since it’s based on Smack, so you’ve got a much better chance at JEP feature-gain than other clients which implement their own XMPP parsers.

    My problem is that for me, any client *must look native*, and Swing just doesn’t (even in the WinLAF). I spent a few minutes wondering about how hard it would be to port JBother to SWT, but then I decided “too hard” πŸ™‚

    I have glanced at the JBother source code (I’ve not looked in detail), and I’m not sure how

  3. Oops, mucked up that comment a bit, sorry. Ignore the last half-sentence πŸ™‚

  4. You’re right, GAIM does support Jabber, but getting UI patches commited is likely to be a nightmare seeing as it’s a cross-platform client and I (currently) only have Windows machines available to me.

    Also, the worst UI bug on Windows is a bug in GTK, so for someone not steeped in GTK lore like me, it’s almost pointless.

  5. Some remarks:
    1) you say there are 14 servers, this is not true: there are even more servers :O) e.g. Tigase, Ambriosa and chime (three new open source servers) are not listed. I also heard Sun has a server with XMPP support…and there are probably more…

    2) recommended clients: one client that is missing in that list is Coccinella ( http://hem.fyristorg.com/matben/ ). This client is written in Tcl/tk (which is a relative easy language they say to me), it has many cool features, it is not death, it is multiplatform, it supports many JEPs, it should be fully XMPP compatible,… Oh yes, about the user interface: Matts (the auther of the client) started doing cvs commits for Tile support ( http://tktable.sourceforge.net/tile/ ).

  6. Sander, you’re right of course, there are seemingly hundreds of servers. πŸ™‚

    Apple are bundling one in their next OSX release aren’t they? I can’t remember which one off-hand though.

    I didn’t mention the Coccinella because it’s not on the recommended client list for any platform. I’m only really interested in platform-specific clients, too (or ones with sufficient work to make them look and feel native on each platform they run on), so that also rules out the Coccinella.

Comments are closed.