A lot of things happened this year to make me wonder if it isn’t time to stop covering technology for a living, but a couple of weeks ago, I was given a ray of hope, in the form of Microsoft’s exposure of an XMPP interface for the Windows Live Messenger network.
[WP_IMAGE]
People who know me might be a little surprised by that, because if there’s one technology that I simply cannot abide, it’s instant messaging. As I’ve said elsewhere, it combines the worst features of telephone and e-mail by mixing synchronous conversations (e.g., the telephone) with asynchronous ones, and gives the user a third tool that has to be monitored throughout the work day, if not 24×7. In my experience, “instant pestering” is a tool beloved by bosses who don’t trust their employees to work without constant supervision.Nevertheless, I recognize that a lot of work gets done over IM, and generally, end-users seem to like having it at their disposal. The problem is that historically, IM clouds developed as relatively closed systems; although tools such as Trillian sprang up to bridge the competing clouds offered by AOL, Microsoft, Yahoo and others, at first these were fairly kludgy, breaking every time the provider made a change to the back end of the IM service. What was needed was a universal protocol for IM, and XMPP was the answer.
XMPP – the eXtensible Messaging and Presence Protocol – began its life in 1999 as the Jabber project, and is now a de facto standard for communication among the various IM clouds. How far each IM service goes in utilizing XMPP is a complicated story, however; GoogleTalk may be the closest thing to a major service using XMPP whole-hog, but services such as AOL Instant Messenger (and Apple iChat, which piggybacks on AOL’s implementation) Facebook Chat and Meebo all implement XMPP to one degree or another. Even corporate IM standbys such as IBM Lotus Sametime can take advantage of XMPP through a gateway service.
So what Microsoft’s done is open up the Messenger network, allowing developers to write their own client software that authenticates using OAuth 2.0. For now, the XMPP support is limited to the core specification (RFC 6120), most of the instant messaging and presence specs (RFC 6121, except for roster management), fetching of vCards (but not updating them), chat state notifications, and delivery delay; nevertheless, that’s more than enough to get the ball rolling.
Although some observers have argued that the most important thing for Microsoft to do with XMPP at this time is to incorporate federation, which would allow the service to interoperate with services such as Google Talk, I see a bigger opportunity that would actually improve the usefulness of XMPP community-wide, and that’s in the way certain XMPP traffic is handled. Currently, an XMPP message is sent as an XML document, which is fine for ordinary text, but horrible for binary attachments. The latter have to be encoded as a Base64 file, as is done with e-mail attachments that use MIME; until an truly efficient binary XML scheme is developed – and Efficient XML Interchange (EXI) isn’t it – XMPP will just have to make do.
But if Microsoft really wanted to give something back to the community, it could do a lot worse than to put some of its best brains on the chore of making binary XML work well, without requiring the recipient to have a copy of the data schema, as is the case with EXI.