
XMPP over websockets [HTML5] - julien
http://blog.superfeedr.com/xmpp-over-websockets/
======
drdaeman
> 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>

------
skeltoac
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.)

~~~
julien
Don't confuse the protocol and the server! It may be tricky to setup and
ejabberd cluster, but you can't blame XMPP for that!

Also, I wish people were more adventurous with XMPP in general and stop
thinking that it's just a chat protocol.

~~~
rexreed
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?

~~~
seiji
Ick. Do not pass go. Do not collect $200.

For server-to-server passing, prefer (in order):

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

~~~
rexreed
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?

I'd like to learn more!

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

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

------
wicknicks
Very cool! Unfortunately, most browsers are disabling websockets due to
security issues in the websocket protocol itself.

<https://developer.mozilla.org/en/WebSockets>

Can't wait until they fix this!

~~~
julien
We're quite hopeful that this will indeed be fixed very soon!

------
imaginator
This is really great news. Having identity, presence and all the XMPP goodness
delivered to the browser will be great!

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

------
younata
I wonder if it would at all be possible to do the reverse - do html over xmpp?

With the advantages xmpp may or may not have over http/html, this could be
interesting.

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

~~~
rdtsc
> using XMPP and ejabberd as a message backplane for your website

Why not 0mq and json ? Something like Mongrel2 perhaps?

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

------
devinfoley
Very cool! I might switch from OpenFire to ejabbered just to use this if it
continues to mature.

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

