Is XMPP for the web ready?

A discussion started recently on the Jabber social mailing-list about the current state of XMPP support at Facebook. If you don’t remember the idea of a XMPP network for Facebook I’d say it’s rather normal considering they talked about it back in May 2008 and nothing has really happened since then. The discussion has quickly drifted toward the difficulty XMPP knows to really make it big and you can sense some despair within the community.

It seems there are several reasons for this.

First and foremost, XMPP is rather poorly integrated within browsers. Today you have to be part of the browser if you want to succeed. Perhaps the response will come from the rather brilliant lib Strophe. Strophe uses BOSH to connect to XMPP services since Javascript doesn’t offer much access to the low level socket connection object. I hope in the future browsers will offer a built-in XMPP API that can be accessed from Javascript allowing to avoid using BOSH.

Second of all, we need big players to start accepting to let go and start entering Jabber federations so that interoperability actually works. I assume companies have yet to find a way on how they can exercise control over the data they might expose through XMPP whilst finding a way to monetize them.

Third I’d say there is a critical lack of PR around XMPP as an added value to the business. To be honest there is the same issue with AtomPub in my opinion. Both are fantastic technologies but they don’t sell by themselves and I find there is a lack of support from companies to support them. SOAP might have been a crap technology but it was backed up by large businesses that were competing with each other (for the worse one might argue).

Finally, and to me this is the most critical reason, XMPP doesn’t integrate well with the web in general. From the browser side as I suggested above to the fact that it’s rather hard to combine web application with jabber ones. Its definitely doable but requires some careful attention to your architecture. Jack Moffitt argues it’s not XMPP’s fault. It’s quite true as a protocol but I believe it’s not really the right way to invite web developers to push it one step further if you blame them for doing it wrong.

I believe XMPP has tremendous potential but it’s still has some way to go before it finds its place.

12 thoughts on “Is XMPP for the web ready?”

  1. To me the biggest hurdle is the absence of a nice and cool client. Don’t get me wrong, we have tons of IM clients that support XMPP as an Instant Messaging, but nearly none have support for other types of information (PuSub… etc). My bet is that this is changing, and Twhirl is an example). In China QQ has a client that can display webpages!

  2. I hear you Julien but it seems that every other field today is trying to get into the browser so XMPP needs to do it too. Having separate clients sounds backward to me and I really hop browsers will integrate XMPP someday. At least libstrophe covers some immediate needs but is it enough? Hard to say.

    But beyond the technology issue, there is a need for big players to open up their data through XMPP.

  3. Sylvain, aren’t you involved with a project involving xmpp, atompub and a custom protocol called “LLUP”? Whatever happened to that project ?

  4. Brad,

    Yes I am. The idea behind LLUP isn’t dead in the sense that it’s all about defining the best format for standalone messages that contain enough information to determine a resource, some boundary dates, geolocalisation and semantic about that resource.

    I’ve been trying to combine XMPP/PubSub and AtomPub to transport, index and query those messages but as I suggest in this blog post is that it’s currently difficult to achieve this due the mistmatch between XMPP and HTTP.

  5. I’d wonder if there were a JSON based XMPP server/service/whatever whether that might be more palatable to developers. After working with JSON, I’ve become a real fan. It is excellent for data and it seems that XMPP relationship to XML might prevent some folks from getting excited about in programmatic terms (PubSub). This is really a buzzword argument that I’m making without knowing the protocol. But, I am curious if XMPP requires XML at the protocol level or whether that is just the current trend for servers.

  6. Possibly Eric but I doubt XML is the culprit here (mind you a BOSH proxy transforming XML to JSon might be attractive to many). I think there is a strong mismatch between XMPP and HTTP and it makes it rather hard for both to co-exist easily.

  7. Is there a good (unbiased) comparison of XMPP and HTTP by someone that knows both very well? There are obviously serious differences, but I’d like an actual list. Things like ‘client initiates connection’ or ‘message correlation outside a socket connection’ or ‘trust between more than two parties’, etc.

  8. @MikeD: Not sure if it helps, but architectural differences between XMPP and HTTP are described in the upcoming O’Reilly book “XMPP: The Definitive Guide”. The book also links aspects of XMPP to HTTP throughout.

  9. Isn’t the mismatch between XMPP and HTTP their strongest feature? HTTP is a stateless transport protocol, XMPP is a connection-preserving XML routing protocol. They are fundamentally different, have different purposes, different use cases. That said, I would love to see XMPP in the browser. Between the two protocols, that would cover a lot of different
    uses. But it is because of their differences that XMPP is
    useful, not despite them.

  10. Normally I would agree that integrating a new protocol in the browser is hard. However, I tried this open source project (kaazing.org) awhile back and it seemed like a very compelling solution, but I never got a chance to finish the testing. They claim that they have solved the issue of running a native XMPP client in the browser. Would be great to hear if someone else have tried it out.

Comments are closed.