Aaron Miller wrote:
Seems to point to a larger issue. With over 100 million users, we need
them in the game. Otherwise, it's just Google on the numbers. Why isn't
this protocol important to Web communities? I'm primarily a web
developer, who has integrated XMPP through BOSH on my own network, and
even integrating with Google is a difficult prospect, since they only
implement a few extensions. Not just that, but the social aspect of it:
people associate XMPP with IM, and this is somehow antithetical to the
old in-out missionary style of server-client HTTP. Personally, I don't
believe this, but from contact with the Web community, I know it to be
true.
I'm very keen on XMPP, but disagree with a line of thought that says web
communities have a responsibility to make XMPP deployments a reality.
First, without meaning to be facetious, XMPP is not a Web technoogy.
Asking why isn't it important to Web communities doesn't add up.
Second, I think there are some good systems reasons why XMPP doesn't get
deployed:
- load balancing. Anyone here know how to build out an XMPP deployment
that has hundreds of thousands to low millions of users, never mind 50M+?
- clustering. Fwiw, I don't think it's easy enough to cluster XMPP
servers compared to web farms. Generic Tools like pound/perlbal mostly
don't exist in the XMPP world. The OSS stacks I've seen, ejabberd,
openfire, jabberd2 are limited to what I'd call "lan scale". To work
with long lived connections at this scale you have to be using epoll.
- rosters and presence. What can I say?
XMPP experts are welcome to disagree, but I've seen enough to say that
fronting scalable XMPP deployments are a black art, much the way
scalable HTTP deployments were a decade ago. I'm talking about
*deployments* here - I'm not questioning whether XMPP itself is a
scalable protocol.
I like XMPP, but seriously, from the Web side of things, I think the
perspective must be that this is somehow competing with more
HTTP-centric things like Atom, APP and REST.
I know something about those 3 and I can't agree. Nobody I think really
wants to build web services that require being hammered via polling, but
we do at least know how to build systems to hold up under that.
People tend to use comet/bosh solutions, since even though they seem to
suck technically the traffic and capacity characteristics are well
understood and fit with existing web infrastructure. I call this pattern
in general "push to pull" - it's also similar to email - we know it can
be massively scaled.
Or just that this is too
difficult and/or buggy to deal with.
This is closer to the truth. When architectural models akin to LAMP/JAMP
exist for XMPP, things will change.
Personally, I think it could bring
a new dimension to the Web.
XMPP is not the Web. It's a different system.
And I think a lot of Web folks think so. For
a bit, it seemed that Twitter was almost going to do it, and a few
others too. But something always rears its head to deter people from
experimenting too much with XMPP.
It was disappointing to see that, but the truth is, internet scale push
is not a solved problem. Polling, frankly, remains hugely effective.
There's a very good chance that web hooks/trackback style approaches
will see better uptake than push/firehose approaches as a result.
I'd like to see something happen to change this. I know that's kind of
what this list has been about. Just throwing this out there as a tidbit
from the other side, since the list has been quiet for so long ... food
for thought.
I would start with figuring out how to cluster XMPP farms.
Bill
