« Ant+Ivy | Main | YouTube via GData »

XMPP matters

Tim Bray:

"There are two problems with Push that don’t arise in Pull: First, what happens when the other end gets overrun, and you don’t want to lose things? And second, what happens when all of a sudden you have a huge number of clients wanting to be pushed to? This is important, because Push is what you’d like in a lot of apps. So it doesn’t seem that important to me whether you push with XMPP or something"

Overrun clients. Unfortunately, this does arise in pull, which is why I brought up feed archive paging and the rate of publish-to-pull, which becomes critical as the gap widens or when the client is downed for while. Operationally, it's the same effect as queues overrunning in push scenarios - messages are dropped on the floor. At that point, you don't care about how traffic flow is initialized any more.

Huge number of clients. This is a job for XEP 60 Publish-Subscribe using a scalable server such as ejabberd. PubSub subscriptions are to nodes, which are logically named; that means you can run a server farm to back subscription services if you want to. And you can build a lattice of subscription nodes if EDA is your thing.

I'd take XMPP as a messaging backbone over AMQP, which Tim mentions because he's thinking about buffering message backlog, something that AMQP calls out specifically. And as he said - "I’ve been expecting message-queuing to heat up since late 2003." AMQP is a complicated, single purpose protocol, and history suggests that simple general purpose protocols get bent to fit, and win out. Tim knows this trend. So here's my current thinking, which hasn't changed in a long while - long haul, over-Internet MQ will happen over XMPP or Atompub. That said, AMQP is probably better than the WS-* canon of RM specs; and you can probably bind it to XMPP or adopt its best ideas. Plus, I'm all for using bugtrackers :)

So I think XMPP matters insofar as these issues are touched on, either in the core design or in supporting XEPs, or reading protocol tea leaves. XMPP's potential is huge; I suspect it will crush everything in sight just like HTTP did.

A real interesting long bet is to wonder how much voice traffic will be done over XMPP. Who knows what's possible with XMPP/Jingle servers running on something like Tamarin or Gaim. Jingle is not well known - essentially it's an extension to XMPP that uses a P2P connection model, and failing that, support for negotiating NAT traversals, STUN, or if all else fails, server relays.



August 28, 2007 11:45 PM