Re:XMPP Myths
by Arathorn on Tuesday August 11, 2015 @12:31PM
(#10042350)
+1 that JSON-over-WS is not a panacea. Long-polling is inelegant but is pretty efficient with HTTP/2.0, and trivially degrades on older HTTP stacks (e.g. in embedded devices) which don't know anything about WS.
Dave Cridland's wiki page makes some good points, but predictably it paints a very black and white view of the world. Some contentious points are:
1. Myth One: XMPP is XML, so it's too slow.
...there are obviously faster encodings than XML out there (e.g. CBOR), so this feels like a slightly specious point to argue. Sure the difference isn't that important on the clientside (perhaps more of an issue for squeezing every last drop out of a server), but why not acknowledge it?
2. Myth Two: The baseline is minimal, therefore XMPP is useless.
I'm not sure anyone claims XMPP is useless just because its baseline is minimal. The issue is instead the fragmentation caused by lack of interoperability profiles for all the different extensions. Statistically, if I pick an arbitrary XMPP client and an arbitrary XMPP server, the overlap of supported XEPs is unlikely to provide a good modern comms experience. If it was a "bug" for your client or server not to implement a given critical XEP, then fragmentation would be less of an issue.
3. Myth Three: It's too bandwidth-inefficient for mobile.
Just because you can successfully talk XMPP over a 9600bps link with 30s of latency doesn't mean that the default transport is bandwidth efficient(!) That said, the XEPs for constrained networks are a better justification.
4. Myth Four: XMPP is unreliable without a bunch of extensions.
As Dave repeatedly says, XMPP is a NAK protocol - by default messages are not acknowledged, so whenever a TCP stream drops you have no way of knowing whether the last messages in the stream got through or not. This is to me the definition of an unreliable delivery mechanism, and you have to mitigate it with extensions (XEP-198). I'm still not sure how this one's a myth...
5. Myth Five : XMPP is unsuited to the web.
The hypothesis of "XMPP is unsuited to the web because angle brackets and stuff" isn't exactly well articulated here. I think the actual complaint here is "why bother putting an XMPP stack in your browser when you already have an HTTP stack there"? What value do the remnants of XMPP's transport semantics have when you already have HTTP as a transport? I agree that Stanza.io & XMPP-FTW make this less clear cut, however.
For what it's worth, the FAQ entry that triggered this wiki page can be found at http://matrix.org/blog/faq/ (What’s the difference between Matrix and XMPP?).
Dave Cridland's wiki page makes some good points, but predictably it paints a very black and white view of the world. Some contentious points are:
1. Myth One: XMPP is XML, so it's too slow.
...there are obviously faster encodings than XML out there (e.g. CBOR), so this feels like a slightly specious point to argue. Sure the difference isn't that important on the clientside (perhaps more of an issue for squeezing every last drop out of a server), but why not acknowledge it?
2. Myth Two: The baseline is minimal, therefore XMPP is useless.
I'm not sure anyone claims XMPP is useless just because its baseline is minimal. The issue is instead the fragmentation caused by lack of interoperability profiles for all the different extensions. Statistically, if I pick an arbitrary XMPP client and an arbitrary XMPP server, the overlap of supported XEPs is unlikely to provide a good modern comms experience. If it was a "bug" for your client or server not to implement a given critical XEP, then fragmentation would be less of an issue.
3. Myth Three: It's too bandwidth-inefficient for mobile.
Just because you can successfully talk XMPP over a 9600bps link with 30s of latency doesn't mean that the default transport is bandwidth efficient(!) That said, the XEPs for constrained networks are a better justification.
4. Myth Four: XMPP is unreliable without a bunch of extensions.
As Dave repeatedly says, XMPP is a NAK protocol - by default messages are not acknowledged, so whenever a TCP stream drops you have no way of knowing whether the last messages in the stream got through or not. This is to me the definition of an unreliable delivery mechanism, and you have to mitigate it with extensions (XEP-198). I'm still not sure how this one's a myth...
5. Myth Five : XMPP is unsuited to the web.
The hypothesis of "XMPP is unsuited to the web because angle brackets and stuff" isn't exactly well articulated here. I think the actual complaint here is "why bother putting an XMPP stack in your browser when you already have an HTTP stack there"? What value do the remnants of XMPP's transport semantics have when you already have HTTP as a transport? I agree that Stanza.io & XMPP-FTW make this less clear cut, however.
For what it's worth, the FAQ entry that triggered this wiki page can be found at http://matrix.org/blog/faq/ (What’s the difference between Matrix and XMPP?).