7 comments on “XMPP

  1. Nic Wise says:

    I know google talk is based on XMPP, and I think Twitter uses it behind the scenes, but I’m not sure.

  2. maetl says:

    Last year, I set up a Jabber bot on a spare Ubuntu box that I was using for testing website integration. The bot would hammer the command line to check out projects from SVN and run unit tests. Using the Jabber interface, you could connect to it via Google Talk or what-not, and send commands to it, and it would reply in the chat with information about the project status.

    Fairly primitive, but from what little I did, I could see much more potential. The other thing was that it was very easy to set up using just stuff packaged in Ruby Gems, and I didn’t need any specific knowledge about XMPP or Jabber to get it working.

    See: http://socket7.net/software/jabber-bot

  3. bwooce says:

    Hmmm. I’ve been running Jabber/XMPP servers for quite some time. Since 2003 at least, although my home domain has only been running for a year or two. The best one at the moment is even in my favourite language, Erlang (ejabberd).

    XMPP has many things right, but is also being misused for things it is not good at. It isn’t good at reliable transport for example…just kinda, sorta, reliable. That could be good enough for some applications.

    See this guy for some good information about some of the limitations of XMPP. Most of the answers from the leaders of the XMPP organisation are “well TCP doesn’t work well, but tunnelling it over HTTP works great so use that”. This is a huge WTF to my mind. It would be all right if it had started out intending to use HTTP as a transport, but it was bolted on later.

    If you want to see a nice protocol definition, one that is being used as a great bearer for other protocol information, check out DIAMETER. They didn’t let the coffee boy loose to design a protocol; they understood the limitations of TCP and didn’t bind their protocol directly to it. Event mandated SCTP support. It has a nice extension system of “Applications”, simple encoding, and wide support.

    I’d suggests that AMQP is a better fit for the cloud given it doesn’t come with all the IM legacy XMPP inherited from Jabber (a name change, but also the push to become more than IM). My former colleague TonyGJ has been working hard on RabbitMQ which is a kick-arse implementation of this. It is an open middleware that supports the publish and subscribe model you’re probably most interested in?

    xmpp://bruce@fitzsimons.org

  4. bwooce says:

    OT: I get “System Error” when trying to post a comment on that website, and due to the Web 2.0 goodness the back button erases my comment. UX Fail.

  5. Back in 2002 I was working on an XMPP based taxi dispatch system. The taxi’s talked XMPP over GPRS to the central server reporting back GPS locations, and dispatch statuses which the central server used to allocate jobs to the most appropriately located (and available) cab,

    Sadly the project died due to financial disagreements between the clients two partners.

    Before leaving my old job I was also starting to work on an XMPP based distributed mail polling process for $oldemployers Blackberry like push-email solution, making use of XMPPs presence notification to allow the central server/controller to allocate/distribute/partition its load across what ever polling agents were active, and what they supported.

    XMPP is great once you look beyond the simple “instant messenger” side of things – it was always targetted towards being an XML router along side being an open messaging platform.

  6. bwooce says:

    Mark: Have you actually tried the protocol over GPRS? GPRS makes the problem of the tight binding between XMPP and TCP much more evident.

    GPRS devices go dormant with open TCP connections all the time, so packets from or to them can be accepted into the OS TCP buffer when they’re not really there. XMPP defines this as “sent”. If the TCP connection cannot be re-established because the connection broke while dormant then this packet (or packets) are silently lost. The connection is broken but there is no way of telling if the message(s) were received. This is a problem for most applications unless they place another “reliability” layer on top of the two already there (XMPP and TCP) – see XEP0079. Presence which is based on the presence (sigh) of the TCP connection is similarly a bit stuffed.

    Then there is the glorious inefficiency of the presence information soaking up GPRS bandwidth, although in your model I would imagine every car didn’t need to know about the status of every other car :-)

    Jabber clearly did start as an open IM platform. It was the open answer to the 90’s proprietary IM (ignoring IRC) craze. The change to XMPP was still driven by these IETF requirements, which RFC 3920 acknowledges.

    There are other ways to get pub-sub functionality, and the easy availability of XMPP servers and client libraries doesn’t mean that it is the best way. All protocols have faults (see TCP), but I’ve found the XMPP community reluctant to admit any exist.

    This reddit conversation puts it far better than I could. Googling XMPP AMQP has proven to be very educational though.

  7. Seth Wagoner says:

    There is awesome potential in this area and I’ve been looking into it quite closely this year. If you’re interested in having a chat about it sometime let me know. XMPP has come a long way since the late 90s.

Comments are closed.