3 ms·

Indeed. I work with XMPP daily and share your views. However XML can be horrific, and I do dread working with it in many applications (remember SOAP?). I assume

Indeed. I work with XMPP daily and share your views. However XML can be horrific, and I do dread working with it in many applications (remember SOAP?). I assume people transfer these experiences easily. One thing that can be annoying is that some environments don't have streaming ("SAX") parsers readily available. That's less of a problem these days, but framing would have helped implementers in that regard. However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing.

yamtaddle 4y ago
> Indeed. I work with XMPP daily and share your views. However XML can be horrific, and I do dread working with it in many applications (remember SOAP?). I assume people transfer these experiences easily. Oh, sure, XML can be a nightmare, it was just good enough in XMPP's case that I doubt anything else would have been much easier/better. There were some minor annoyances and awkwardness, but that's hard to completely eliminate in that kind of thing. Its using XML wouldn't have made any list of notable challenges on that project, for sure. > However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing. Oh wow, nice. IIRC I used Comet(?), which was my only big client-side dependency, to talk to a very simple bridge I wrote (probably Nodejs?) and OpenFire for the daemon, solely because it was stupid-easy to write a custom auth class (it's Java) so it could share accounts with our broader product without needing to modify any other parts of the system. Having some of that—at least the HTTP-bridge portion—already covered would have made it even easier.
- MattJ100 4y ago
  Since you mentioned comet, one of my favourite solutions for sending realtime stuff to web browsers is Server-Sent Events. It's just so simple. I wrote an XMPP bridge for it at: https://modules.prosody.im/mod_pubsub_eventsource https://modules.prosody.im/mod_pubsub_eventsource Of course if you need bidirectional (and not REST) then you generally need to upgrade to websockets.

yamtaddle 4y ago

> Indeed. I work with XMPP daily and share your views. However XML can be horrific, and I do dread working with it in many applications (remember SOAP?). I assume people transfer these experiences easily. Oh, sure, XML can be a nightmare, it was just good enough in XMPP's case that I doubt anything else would have been much easier/better. There were some minor annoyances and awkwardness, but that's hard to completely eliminate in that kind of thing. Its using XML wouldn't have made any list of notable challenges on that project, for sure. > However we do have XMPP-over-websocket defined these days (which doesn't have to be used only in a browser) and that has framing. Oh wow, nice. IIRC I used Comet(?), which was my only big client-side dependency, to talk to a very simple bridge I wrote (probably Nodejs?) and OpenFire for the daemon, solely because it was stupid-easy to write a custom auth class (it's Java) so it could share accounts with our broader product without needing to modify any other parts of the system. Having some of that—at least the HTTP-bridge portion—already covered would have made it even easier.

MattJ100 4y ago
Since you mentioned comet, one of my favourite solutions for sending realtime stuff to web browsers is Server-Sent Events. It's just so simple. I wrote an XMPP bridge for it at: https://modules.prosody.im/mod_pubsub_eventsource https://modules.prosody.im/mod_pubsub_eventsource Of course if you need bidirectional (and not REST) then you generally need to upgrade to websockets.