Gnip Says XMPP Ecosytem Too Half-Baked, Pulls the Plug
readwriteweb.com
readwriteweb.com
The question is if XMPP can be made into an efficient application for streaming events to multiple (or multitudes of) subscribers. Chat is a 1-to-1 limited tima affair. PubSub is not. I am afraid this is not simply a matter of a bette rimplementation of an XMPP server but something much more fundamental. Roy fielding has argued (http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-d...) why the economics of XMPP for pub/sub do not work out and why the solution is simply to better structure the HTTP APIs that the various services provide. This is why large customers are needed. There is cost involved and somebody has to pay it. The recent Twitter/Gnip moves serve as testament to Roy's foresight.
One thing that I think makes XMPP so heavyweight is that it's XML. And it took so long to get off the ground because the documentation was like "here, look, it's so easy to send messages over Jabber, it's just XML" but didn't really explain all the "presence" terminology nor provide libraries for a number of popular languages initially that hid all the complexity and let you actually join to a server. Even the perl XMPP library on CPAN talks about "XML stanzas" -- dude, all I want to do is join a server and send and receive messages, hook me up to an event loop! (admittedly, the perl module in question does this, there's just a lot of XMPP baggage to get around). XMPP also include{s,d} a lot of complexity for things that normally happen out of band for security purposes, like user creation on the servers. I mean, XMPP makes the IMAP protocol look simple.
But almost nobody uses it. It is even more half-baked than XMPP. I guess this is a tradeoff.