> it’s by far the greatest protocol to “push” content from a server to client
Except it's messy and ugly. Well, it's somehow feels on par with HTML, where browsers have to support all sorts of weirdness, though. Further reading: http://news.ycombinator.com/item?id=2069810
As a big fan of and small contributor to ejabberd (I run im.wordpress.com), one who has used Jack's excellent strophe.js, and one who is anxious to see websockets in more use cases, I was pleased to read this news.
However, I still consider XMPP as the protocol of last resort when designing apps for the browser that don't map perfectly onto XMPP. I would sooner write a new protocol than set up a new ejabberd cluster. (This opinion is based on the quality of documentation available a year ago and may be out of date.)
I've been using ejabberd a lot lately and it's a really nice piece of software, and works very well.
My biggest problem with XMPP as a whole is... well, it's XML. Not only is it heavier than it should be across the wire, it feels to me that the XML way of thinking leads to unnecessary verbosity when designing protocol messages. And there seems to be no proper consensus on how to use it among the different XMPP RFCs -- do we re-use a node name or come up with something different? Or just make it an attribute? Do we namespace it?
XMPP works great for what it was designed for though. There are many robust client and server implementations, being able to federate is awesome, and it's pretty easy to extend. But if I were to re-invent it, I would use a binary transport format.
We're actually thinking of using XMPP as a server-to-server asynchronous messaging / pubsub protocol to help us with distributed processing and long running transactions. But I am already stretching my knowledge in this area and would love to chat with others who are thinking of using XMPP as a server-to-server protocol. Julien - can I pick your brain?
1. redis pubsub
2. zeromq (if you know what you're doing)
3. amqp (if you think you need it)
4. populate events to a DB transactionally then consume later
Only use XMPP if your problem domain is "someone is paying me $LOTS to set up an XMPP service."
I'd like to understand more about this and your thoughts. Have you had experience using XMPP this way? Is there a specific reason why this wouldn't / shouldn't work? I know you prefer the other approaches, but other than simply preferring them, what is the issue with using XMPP this way?
Specifically, what if the scenario is enabling communication between servers that you have limited control over and do not have shell / root access to install or manage a server? In this case, there wouldn't be an opportunity to install redis, 0mq, or amqp. The database approach might work, but the servers are distributed and might not allow remote connections. Why wouldn't XMPP work in this scenario using a public XMPP server?
First, XMPP obviously works. Google Chat is XMPP. Facebook Chat is XMPP (ejabberd). But SOAP works too. Doesn't mean I want to use it.
My problem with XMPP is best illustrated by XEP-0060, the pubsub extension proposal: http://xmpp.org/extensions/xep-0060.html -- I don't have time to figure out that monstrosity.
AMQP is at the limit of complexity as far as pubsub things go. It's complex enough to need explaining, but simple enough were you can understand it in an hour.
If you want an in-depth discussion war about pros and cons, ask your question both on the redis mailing list and on the rabbitmq mailing list. I'd be interested in seeing how both communities respond to your requirement of running on limited access servers.
Thanks for the response! Ok, so to summarize, XMPP works, but in your opinion, it's simply too complex to "figure out"? Basically, in my scenario, it could very well work as optimally as we want it to if we give ourselves time to understand it?
I wish I could use zeromq or redis or amqp, but it just is not an option in this environment.
I was wondering if there was some solid technical reason to not use XMPP, but it looks like there isn't one... it's just a matter of personal preference and wanting to avoid spending time on something. I'll charge ahead with the XMPP implementation in our scenario unless there's a good reason someone can see why not to.
Twitter had an XMPP feed at one point, but shut it down due to scaling issues and later brought up their current firehose/sitestreams service. Does anyone know if they ever talked about why XMPP didn't scale for them?
Site streams requires making one connection per 100 users; perhaps they were having trouble sharding with XMPP?
I think they were mostly having issues because people would enter their gtalk jid to get content... and google obviously throttles the traffic pretty aggressively, so dev would not receive the content and would complain.
By any means I'll stand on a point that using pure XMPP from a JS point of view is a total over utilization. XMPP is perfect when you're able to make it fit your needs and (more important) you are able to hide it's extreme complexity from your user.
XMPP can carry anything, but it can more easily carry XML-based formats like XHTML. But given that, yes. Formatted IM messages are already specified as a subset of XHTML and you can trivially create your own messages that do whatever custom thing you want with XHTML on your page, or float your custom addition on top of existing messages as a namespaced addition.
The most interesting obvious usecase to me would be using XMPP and ejabberd as a message backplane for your website, hanging various components off of ejabberd that can integrate with your web connection.
Because then you'd have to implement your own presence, discovery, and routing mechanisms. You get all of that (and more) for free with an XMPP backplane like ejabberd. Even if you decide it's better to roll your own, you'll then have to come up with a consistency and clustering model in order to scale it.
I'd argue that ejabberd is faaar more mature than OpenFire. Their web gui is a little less polished but last I checked OpenFire's clustering mechanism is "buy very expensive oracle database". Still for small (under 100 users) installations without uptime guarantees OpenFire is easier to set up.
Except it's messy and ugly. Well, it's somehow feels on par with HTML, where browsers have to support all sorts of weirdness, though. Further reading: http://news.ycombinator.com/item?id=2069810