
Gnip Says XMPP Ecosytem Too Half-Baked, Pulls the Plug - danw
http://www.readwriteweb.com/archives/gnip_says_xmpp_ecosytem_too_ha.php
======
alexandros
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...](http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-
dragons)) 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.

~~~
thwarted
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.

~~~
rincewind
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.

<http://about.psyc.eu/PSYC>

But almost nobody uses it. It is even more half-baked than XMPP. I guess this
is a tradeoff.

------
einarvollset
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.

------
mindaugas
Maybe AMQP is the answer?

------
crabapple
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

~~~
bpm140
Sort of like what happened to Feedburner, right?

