5 ms·

XMPP over websockets [HTML5]

76 points by julien 16y ago

younata 16y ago
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 16y ago
  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 16y ago
    > using XMPP and ejabberd as a message backplane for your website Why not 0mq and json ? Something like Mongrel2 perhaps?
    - slysf 16y ago
      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.
drdaeman 16y ago
> 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 http://news.ycombinator.com/item?id=2069810
devinfoley 16y ago
Very cool! I might switch from OpenFire to ejabbered just to use this if it continues to mature.
- julien 16y ago
  We will keep working on this as we will obviously use it ourselves :)
- slysf 16y ago
  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.
skeltoac 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
        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!
imaginator 16y ago
This is really great news. Having identity, presence and all the XMPP goodness delivered to the browser will be great!
wicknicks 16y ago
Very cool! Unfortunately, most browsers are disabling websockets due to security issues in the websocket protocol itself. https://developer.mozilla.org/en/WebSockets https://developer.mozilla.org/en/WebSockets Can't wait until they fix this!
- julien 16y ago
  We're quite hopeful that this will indeed be fixed very soon!
Fester 16y ago
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.

76 points by julien 16y ago

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 16y ago
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 16y ago
  > using XMPP and ejabberd as a message backplane for your website Why not 0mq and json ? Something like Mongrel2 perhaps?
  - slysf 16y ago
    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.

drdaeman 16y ago

> 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 http://news.ycombinator.com/item?id=2069810

devinfoley 16y ago

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

julien 16y ago
We will keep working on this as we will obviously use it ourselves :)
slysf 16y ago
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.

skeltoac 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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!

imaginator 16y ago

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

wicknicks 16y ago

Very cool! Unfortunately, most browsers are disabling websockets due to security issues in the websocket protocol itself. https://developer.mozilla.org/en/WebSockets https://developer.mozilla.org/en/WebSockets Can't wait until they fix this!

julien 16y ago
We're quite hopeful that this will indeed be fixed very soon!

Fester 16y ago

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.