Good protocols have a layered design where you deal with different concerns in a fashion that promotes simplicity, robustness and performance. For instance first the complexity in framing individual messages, then the way you represent the payload (on at least 2 levels), and then the semantics you can layer on top of that.
Using XML framing in XMPP was the opposite of simplicity. (Sure it was simple in the sense that it required zero experience with actual implementation of protocols to arrive at the conclusion, but the result was something that was harder to implement properly).
It is "simple" for moronic, bad, implementations of the protocol, but it only complicates the situation when you need performance, quality and efficiency. It complicates it greatly. In essence, you end up having to write two parsers: a shallow framing parser and a deep parser.
And if you think you are going to get any help from the fact that there are lots of XML parsers: I've got bad news for you. There's lots of XML parsers that are meant to parse documents. Not millions of simultaneous, "endless" streams of data from dodgy clients.
XMPP is not good protocol design. It is brutally stupid protocol design.
(An irony is that right now there are several areas where you would want to use a messaging protocol for small devices. This ought to be the moment where a messaging standard had a chance to shine. And XMPP ends up being one of the least desirable protocols because so little care was taken in designing it)
> There's lots of XML parsers that are meant to parse documents.
You obviously wouldn't use such a parser for XMPP. You would use a parser designed for the purpose. Very few people would ever have to even think about the issue, there are XMPP libraries available for pretty much any environment in existence.
This is true for people who write applications. It is not true for people who would like to write servers and XMPP libraries that are somewhat efficient.
XMPP also isn't usable for many new IoT applications where it should have had its opportunity to shine, but where there just isn't enough memory to deal with the ridiculous bulk.
But I do get that most developers don't really try all that hard. I mean, look at the resource usage of Slack. It is an application that does _nothing_ that requires CPU, yet it gobbles it up. It tells you something about the kinds of people that write chat applications today. Not exactly the sharpest tools in the shed.
Well presumably this hypothetical IoT application would have to support TCP/IP. Against that, a few hundred bytes of state table for the limited subset of XML required for basic XMPP would count for much.
Using XML framing in XMPP was the opposite of simplicity. (Sure it was simple in the sense that it required zero experience with actual implementation of protocols to arrive at the conclusion, but the result was something that was harder to implement properly).
It is "simple" for moronic, bad, implementations of the protocol, but it only complicates the situation when you need performance, quality and efficiency. It complicates it greatly. In essence, you end up having to write two parsers: a shallow framing parser and a deep parser.
And if you think you are going to get any help from the fact that there are lots of XML parsers: I've got bad news for you. There's lots of XML parsers that are meant to parse documents. Not millions of simultaneous, "endless" streams of data from dodgy clients.
XMPP is not good protocol design. It is brutally stupid protocol design.
(An irony is that right now there are several areas where you would want to use a messaging protocol for small devices. This ought to be the moment where a messaging standard had a chance to shine. And XMPP ends up being one of the least desirable protocols because so little care was taken in designing it)