4 ms·

Meta preceeded Google in killing XMPP. I'm hopeful but cynical: companies have people on standard's committees for all kinds of other reasons, e.g. for prestige

Meta preceeded Google in killing XMPP. I'm hopeful but cynical: companies have people on standard's committees for all kinds of other reasons, e.g. for prestige.

richardwhiuk 3y ago
Sure, but saying they aren't contributors isn't correct.
Andrex 3y ago
XMPP was either the wrong protocol for the right time, or the right protocol for the wrong time. I'm still not sure.
cyberax 3y ago
XMPP is a horrible protocol. It deserved to die. Who the hell thought that it's a good idea to use a never-ending stream of XML messages that required a custom parser?
- fabrice_d 3y ago
  Not saying that XMPP overall is a great protocol, but you always could parse a XMPP stream with an event based XML parser (eg. a SAX parser). Yes you likely have to implement namespace resolution on top of the event stream, but it's not that hard.
  - MattJ100 3y ago
    Many SAX parsers support namespaces natively. Expat is a popular choice.
    - fabrice_d 3y ago
      I mostly used the one from libxml2 but it's been a while and I could not remember if the SAX parser did namespace resolution :)
- MattJ100 3y ago
  I've created many XMPP implementations, and I've never created a custom XML parser for it (well, some toy ones for various fun things, but not one I'd use in production). You're right that some XML parsers demand the entire document at once, and those are not suitable for XMPP (or any kind of incremental document parsing). Parsers with a SAX-based API for example don't have this limitation.
- vilunov 3y ago
  Protocols have many aspects, and the serialization format is often the least important among them, although it definitely attracts most attention, as it's the easiest to get acknowledged with deeply enough to be able discuss it. XML back then (late 90s-early 00s) was quite an ubiquitous format, more popular than JSON. Websocket itself was drafted in 2010, so you wouldn't be able to come up with something better than a "never-ending stream of XML/JSON messages". The single objectively positive aspect of XML is namespaces. It is very important for "extensibility" part of the protocol, as it allows you to introduce custom elements, which are namespaced by your org's domain name. Protocols such as Matrix [1] and ActivityPub [2] use JSON as the serialization format, but they too support extensibility, and therefore they have to implement namespacing. Which they do, but very differently. [1]: https://spec.matrix.org/latest/#namespacing https://spec.matrix.org/latest/#namespacing [2]: https://www.w3.org/TR/json-ld/#the-context https://www.w3.org/TR/json-ld/#the-context
- Andrew_nenakhov 3y ago
  Xmpp is a good protocol. Zero of its problems were caused by XML. It has many really lousy and badly thought of and mutually inconsistent extensions, but an implementation can always ignore them. All problems XMPP has are caused by the difficult problem which is decentralized messaging. Choose JSON or binary data format and eventually you'll encounter all the same problems again and again.

Meta preceeded Google in killing XMPP. I'm hopeful but cynical: companies have people on standard's committees for all kinds of other reasons, e.g. for prestige.

richardwhiuk 3y ago

Sure, but saying they aren't contributors isn't correct.

Andrex 3y ago

XMPP was either the wrong protocol for the right time, or the right protocol for the wrong time. I'm still not sure.

cyberax 3y ago

XMPP is a horrible protocol. It deserved to die. Who the hell thought that it's a good idea to use a never-ending stream of XML messages that required a custom parser?

fabrice_d 3y ago
Not saying that XMPP overall is a great protocol, but you always could parse a XMPP stream with an event based XML parser (eg. a SAX parser). Yes you likely have to implement namespace resolution on top of the event stream, but it's not that hard.
- MattJ100 3y ago
  Many SAX parsers support namespaces natively. Expat is a popular choice.
  - fabrice_d 3y ago
    I mostly used the one from libxml2 but it's been a while and I could not remember if the SAX parser did namespace resolution :)
MattJ100 3y ago
I've created many XMPP implementations, and I've never created a custom XML parser for it (well, some toy ones for various fun things, but not one I'd use in production). You're right that some XML parsers demand the entire document at once, and those are not suitable for XMPP (or any kind of incremental document parsing). Parsers with a SAX-based API for example don't have this limitation.
vilunov 3y ago
Protocols have many aspects, and the serialization format is often the least important among them, although it definitely attracts most attention, as it's the easiest to get acknowledged with deeply enough to be able discuss it. XML back then (late 90s-early 00s) was quite an ubiquitous format, more popular than JSON. Websocket itself was drafted in 2010, so you wouldn't be able to come up with something better than a "never-ending stream of XML/JSON messages". The single objectively positive aspect of XML is namespaces. It is very important for "extensibility" part of the protocol, as it allows you to introduce custom elements, which are namespaced by your org's domain name. Protocols such as Matrix [1] and ActivityPub [2] use JSON as the serialization format, but they too support extensibility, and therefore they have to implement namespacing. Which they do, but very differently. [1]: https://spec.matrix.org/latest/#namespacing https://spec.matrix.org/latest/#namespacing [2]: https://www.w3.org/TR/json-ld/#the-context https://www.w3.org/TR/json-ld/#the-context
Andrew_nenakhov 3y ago
Xmpp is a good protocol. Zero of its problems were caused by XML. It has many really lousy and badly thought of and mutually inconsistent extensions, but an implementation can always ignore them. All problems XMPP has are caused by the difficult problem which is decentralized messaging. Choose JSON or binary data format and eventually you'll encounter all the same problems again and again.