4 ms·

One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe

One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe XMPP basically relies on an unclosed XML document that keeps getting appended to, so you need to have strong partial parsing guarantees that's unusual for XML formats.

riedel 5y ago
Actually removing some stuff from XPath, could give guarantees while parsing partial files. That things get ugly sometimes if XML documents aren't complete, doesn't mean that other encodings are automatically better. People should care about some good hedge grammars for extensible formats instead of getting political about that stupid encoding. There should be sth beyond current XML standards and libraries but please make it not be JSON.
defanor 5y ago
That's indeed a common complaint, though streaming XML parsing is not that uncommon, and there's even a common algorithm/API for that--SAX [1]--supported by multiple libraries; otherwise parsing even finite but large documents (e.g., Wikipedia dumps) would require a lot of memory. [1] https://en.wikipedia.org/wiki/Simple_API_for_XML https://en.wikipedia.org/wiki/Simple_API_for_XML
- duskwuff 5y ago
  That really shouldn't be necessary, though! XMPP is conceptually transmitting a series of independent messages, not an arbitrarily complex document tree. There's no reason why it couldn't have recognized this at the protocol level and transmitted each message independently. (This could have been as simple as placing a CR/LF delimiter between each message and forbidding that sequence within messages.)
gmfawcett 5y ago
It's true that DOM parsers will have a hard time. But event-based, SAX-style parsers have no issue with an unclosed document, and there are plenty of those around (and were around, back in the heyday of XMPP).
- olau 5y ago
  As someone who started writing an XMPP client at the time, I can confirm that the stupid unclosed document was painful. It's a leaky abstraction that goes beyond the parsers (that you can't use). It didn't help that the official documentation heralded this as a beautiful innovation.

riedel 5y ago

Actually removing some stuff from XPath, could give guarantees while parsing partial files. That things get ugly sometimes if XML documents aren't complete, doesn't mean that other encodings are automatically better. People should care about some good hedge grammars for extensible formats instead of getting political about that stupid encoding. There should be sth beyond current XML standards and libraries but please make it not be JSON.

defanor 5y ago

That's indeed a common complaint, though streaming XML parsing is not that uncommon, and there's even a common algorithm/API for that--SAX [1]--supported by multiple libraries; otherwise parsing even finite but large documents (e.g., Wikipedia dumps) would require a lot of memory. [1] https://en.wikipedia.org/wiki/Simple_API_for_XML https://en.wikipedia.org/wiki/Simple_API_for_XML

duskwuff 5y ago
That really shouldn't be necessary, though! XMPP is conceptually transmitting a series of independent messages, not an arbitrarily complex document tree. There's no reason why it couldn't have recognized this at the protocol level and transmitted each message independently. (This could have been as simple as placing a CR/LF delimiter between each message and forbidding that sequence within messages.)

gmfawcett 5y ago

It's true that DOM parsers will have a hard time. But event-based, SAX-style parsers have no issue with an unclosed document, and there are plenty of those around (and were around, back in the heyday of XMPP).

olau 5y ago
As someone who started writing an XMPP client at the time, I can confirm that the stupid unclosed document was painful. It's a leaky abstraction that goes beyond the parsers (that you can't use). It didn't help that the official documentation heralded this as a beautiful innovation.