I posted this on the original article but I might as well post it here as well, with bonus typo corrections.
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.
XMPP is most definitely not a message bus, and message buses or message queues are two technologies that seem like the practical/workable implementation of multicast for the purposes of pubsub.
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.
The "Protocol for Synchronous Conferencing" is an IM protocol that was developed for efficient multicast and pubsub and extensibiltiy. It also has a much simpler(RFC822-like) to parse syntax.
This mirrors my experience with XMPP implementations. It honest to god is a LOT more work than it's worth. If you need a scalable messaging system, hook up a mature JMS implementation (e.g. OpenMQ - search for the article where they got that running with linear speedup over 512 nodes on EC2), and put a STOMP connector at the front for non-java clients.
gnip is one of those cool services that is so fringe that it may have more developers than users. its another sharecropping deal, just like facebook app builders...get too popular, present a threat to unseat the core services...you get unplugged. it would be a triviality to simply block their ip ranges should they ever get traction against the core services' own webservice strategies
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.