XMPP Client Daemon
Sunday, May 21, 2006 by darcoPosted in Jabber
There are many Jabber clients out there for just about every platform imaginable. This is often cited as one of the strengths of Jabber, but it does have serious drawbacks; namely end-user confusion and (for open-source projects)duplicated developer effort. I'm starting to think that the approach that nearly all Jabber clients take is sub-optimal.
One of the primary reasons people are hesitant to adopt 'yet another instant messaging network' is that no single Jabber client does everything that they want. In fact, many people will find themselves using multiple clients for this reason. I know I do. Why switch when none of the jabber clients out there have all of the features which you use with your legacy service?
I don't believe that there will ever be a do-it-all Jabber client—and if there were, I don't know if I would want to use it. The word "Bloated" comes to mind. Instead, I think the solution is to explicitly not create a do-it-all client, but to create a bare-bones jabber service that would provide jabber connectivity to programs which support it. The idea being that it is hard to write a full-featured client, but it is significantly easier to write a program which just provides one service or function.
When we go to set up a new program that uses the internet, we don't have to explicitly provide all of the log-in details for your ISP. You are either already connected to the internet or not, and all of your programs (in general) use the same internet connection. I think that this is the model we should start considering for XMPP. Have a program for instant messaging and roster management, have a program for whiteboards, Have a program for group chat, but they all use the same connection and API.
What I propose is that, on a desktop system, the individual jabber connections themselves should not be handled by the jabber client at all–they should be handled by some sort of Jabber daemon that would establish a single connection to their jabber server upon logging into the computer.
Apple's iChat already does something similar to this. The iChat program itself does not connect to any chat service directly–iChatAgent does. Programs which are designed to use the presence information for your contacts (like Address Book and Apple Mail) will still be able to report correct presence information even when iChat is closed*.
There are certainly a lot of things that would need to be taken into consideration for such a setup (such as security and API standardization), but I think that perhaps that will be the topic of another post on the subject.
Trackback from your own site.
Entries (ATOM/RSS)
Monday, May 22, 2006
Sounds similar to freedesktop.org's telepathy project. It's a really great idea.
Monday, May 22, 2006
sounds cool. the dev behind the now-seemlingly-dead client skabber was also working on a jabber client daemon but his site seems to have disappeared.
Monday, May 22, 2006
eheh...
Last week at work (we maintain a windows jabber client and now a mac jabber client) we where discussing exactly this.
We where discussing taking the Psi core, and removing all the GUI from it, and using some IPC mechanism to keep a GUI outside.
I know of at least one commercial Jabber client that is trying this road. For me it seems a great way to do it.
Best regards,
Monday, May 22, 2006
Hey, this is exactly the point of the Telepathy project which I work on. We've implemented an XMPP backend daemon and export the various functionalities of this (and potentially any other protocol backend) using D-Bus IPC. It's the basis of the IM/VOIP (using Jingle/Google Talk) on the new software release for the Nokia 770.
Monday, May 22, 2006
Somehow this idea sounds familiar to me :/ Just kidding. I was the developer of the wxSkabber client and my last xmpp project was in fact a/the "XMPP Client Daemon".
See http://wxxcd.sourceforge.net/ and http://wxxcd.sourceforge.net/xcd-lib.jpg
Maybe you want to resurrect the project, there is still some code on my HD that is not published in cvs. On the other hand the thelepathy project is basically the same and development is much more active there than mine.
In any case, xcd was already working fine, so it depends on the developer if he wants to do it in c++ or not...
Regards... contact me at: edrin@jabber.org
Monday, May 22, 2006
[TRACKBACK] Questionable efficiency — Is re-inventing the wheel the pinnacle of efficiency, that any new bee XMPP client developer absolutely insists on re-writing yet a new XMPP stack from scratch? Or is XMPP is really lacking an efficient approach at quickly...
Friday, May 26, 2006
[TRACKBACK] Visions pour Jabber — Dans un de mes posts sur le forum de JabberFr.org, je raconte, du point de vue d'un geek/nerd, mes tests très sommaires et fais part de mes reflexions sur les clients Jabber sous Windows (oui, je…