I read this post on the Jive Software blog titled “XMPP (a.k.a. Jabber) is the future for cloud services”. A lot of the technical stuff goes a bit beyond me so this summary on Read/Write Web by Marshall Kirkpatrick was pretty handy. As I understand the whole idea, XMPP (also known as Jabber), the protocol that powers Google Talk and a couple other IM apps/services may be better suited to many new media services and applications than the protocol that is so dominant on the Web at the moment, HTTP. The important aspect of XMPP is that it enables a two way communication process rather than the one way flow that we see with HTTP (ok, I know that isn’t strictly correct but this is how I think about it) so instead of you initiating contact with a Web service using your browser by clicking a link or something like that (HTTP), a Web service can contact your machine first, let it know there are updates and initiate an update process (XMPP). Maybe a better way to explain it is like this:
- When you want to update a page in your browser you need to click “refresh”. You initiate the process of communicating with the web server the page is on and request the updated page data; and
- When you use an XMPP IM client like Google Talk, for example, the IM server will contact your Google Talk app and send it updates without you having to do anything. This process is more efficient than constant polling the server to check for updates.
XMPP opens up possibilities for people wanting to develop services and apps that spontaneously update as and when updates are available rather than constant polling a server for updates. The one application of this that appeals to me is my feedreader. Your feedreader polls the various feeds you subscribe to for updates on a schedule and downloads new feed items when they are available. Imagine what happens if your feedreader runs on XMPP:
Ask yourself what a decentralized, open source infrastructure for real time communication could offer. A lot. As an RSS-head, I’d love to see XMPP let my various RSS clients do more faster and get bogged down in fewer unnecessary activities. RSS is all about speed for me but clients can only do so much so often when they have to pester someone else’s server every time they want to check for new information. Those delays can be of real consequence.
Receiving your feeds as and when they are published may not be a priority for you but this is a pretty good illustration of some of the possibilities. It is also pretty interesting that Google’s Android Mobile OS incorporates XMPP, at the very least because I can certainly see how XMPP could be a great protocol for widespread mobile applications, particularly where those mobile devices are constantly using a cellular connection or wifi.
I doubt very much that this is the end of HTTP but rather it could be the expansion of a generation of apps and services running on this dynamic protocol. It is probably the sort of development that could once again fuel speculation that IM (or the likes of IM) could overtake email as our dominant means of communicating across the Internet. Not sure about that but it is an intriguing possibility although I am not sure that an email replacement that shortens the already pretty quick delivery times of our messages is a good thing. It is bad enough that email creates an expectation of much faster responses to messages we receive (so much so that productivity gurus recommend you only check your email every couple hours or so to maintain some semblance of meaningful productivity) but if we start exchanging data between people using XMPP-based solutions that expectation becomes more unmanageable.
Where XMPP will probably be a tremendous benefit will be for machine to machine communications, the kind of services that are not immediately apparent to us humans and perhaps even running behind the scenes. IM is in your face, you see the updates coming in and either have to respond to watch messages pile up to be dealt with later. The feedreader example may be a good application for XMPP not because of the immediacy of the updates but because it could mean that my less powerful device can pick up updates automatically and on the fly using a more efficient update process. I can imagine that waiting for a mobile device to scan through hundreds of feeds could take time to update whereas a feedreader running on XMPP is almost always up to date so I can grab my device and run instead of waiting a couple minutes for an up to date sync.
Of course there are probably dozens of more useful applications of XMPP that haven’t even occurred to me that we could see rolling out.