4 ms·

Stop Telling Us XMPP Should Use JSON

39 points by todsacerdoti 11mo ago

hasperdi 11mo ago
If they did adopt JSON then it wouldn't be XMPP anymore. As a user, I don't care much. But my experience with XMPP is that was not as solid as other solutions, including closed source ones. I could've been issues in clients' implementation, but overall it wasn't great
- jauntywundrkind 11mo ago
  Extensible, extense thineself.
- ezst 11mo ago
  > my experience with XMPP is that was not as solid as other solutions, including closed source ones. Considering that WhatsApp is essentially an old/non-federating fork of ejabberd (from where this blog post originates), I think XMPP is doing alright in that regard.
  - greatgib 11mo ago
    Looking at how many years ago the fork open, you can easily guess that the protocol doesn't look anything at all like XMPP.
    - ezst 11mo ago
      For sure, it got continuously refined for WA-specific needs over the years, but XMPP very much still is there, lurking in the shadows: https://www.sciencedirect.com/science/article/abs/pii/S1742287615000985 https://www.sciencedirect.com/science/article/abs/pii/S17422...
- RadiozRadioz 11mo ago
  "not as solid" - please explain.
up-n-atom 11mo ago
Is it really a question about processing performance though? I’ve always assumed it was about bandwidth and latency… Communication protocols don’t need to be human-readable because tooling has always provided that at a higher level. A binary protocol just as a text protocol like S-expression or the divine simplicity of IRC is just as digestible when documented. And there are better facilities to have extensibility regardless. I think we can all agree it’s as much a failure as a success if we’re still talking the same points 25 years later.
- zamalek 11mo ago
  XML compresses really well.
  - dafelst 11mo ago
    Because it contains a ton of redundancy
    - zamalek 11mo ago
      Exactly? What's your point? Things have to be low entropy/contain a lot of redundancy in order to compress well.
      - dafelst 11mo ago
        If it were a more compact format, it is likely both the uncompressed AND compressed sizes would be smaller. By your logic, if you 10x'd the length of the XML tags in XMPP then it would be even better since you you would get an even further improved compression ratio. To be clear, I don't have a problem with XML in XMPP since it is negligible overhead, but "it compresses well because it is full of redundancy" is not the argument that should be used to justify it.
        zamalek 11mo ago
        That's a strawman. I am not arguing that we make the tag names longer, I am arguing that there is little benefit to a more concise format. If you are so bandwidth constrained that deflated XML won't do, then I doubt deflated JSON would be good enough either (and that exists anyway, Matrix).
RadiozRadioz 11mo ago
To take a slightly cynical view, but a view I honestly believe in, on the want to switch to JSON: XML looks old, most programmers have shallow opinions and chase new things. It's not parsing performance, computers are plenty fast for text IM. It's not bandwidth, the difference between JSON and XML is negligible after compression. It's not developer ergonomics, any sane programmer is using a library that abstracts either format. It's not compatibility with the domain, as XML wins for XMPP due to namespaces. The answer is that XML looks old. New programmers (half of all programmers have less than 5 years of experience) grew up in a world of JavaScript where XML was "legacy" since the day they arrived. In reality it's kept working fine, while the volume of software has increased around it naturally using the trendy tools. They've not looked back to understand why it was made or why it has merits, it's already got negative connotations and they're caught up in the new stuff. The new stuff has merit too, that is why a programmer is wise to respect both. Also, what use is a stable and mature XML ecosystem when you can earn big nerd points by reinventing XPath for JSON the 5th time?
- rented_mule 11mo ago
  XML and JSON only started about 5 years apart (1996 vs. 2001). I think XML's adoption was more broad more quickly, so the gap felt a bit longer than that (XML was a core part of my jobs from 1998-2007 and JSON ever since). I think more of what makes XML look so much older is the fact that so many new projects have been picking JSON over XML for 10-20 years now, and that's why younger folks have seen much more JSON than XML. My software engineering career started long before either, and I have used both extensively. While I don't think that it makes sense for most well established projects to switch, just as rewrites often don't make sense, I would almost always pick JSON for new projects. Your points are valid, but one part of the ergonomics that you didn't mention is that it's so much easier for humans to read and write JSON, thereby speeding up development, debugging, testing, etc.
zzo38computer 11mo ago
I agree that it should not use JSON. I think it would be better to use DER (or SDSER if streaming is needed) rather than XML or JSON, but that is just my opinion. However, if the existing protocol already uses XML, then that is what it will be, but the new one perhaps would not use XML.
soul_grafitti 11mo ago
Here's a thought - the thing that will ultimately doom XML, and perhaps JSON as well, will be the extra expense XML incurs when being tokenized for LLMs.

39 points by todsacerdoti 11mo ago

If they did adopt JSON then it wouldn't be XMPP anymore. As a user, I don't care much. But my experience with XMPP is that was not as solid as other solutions, including closed source ones. I could've been issues in clients' implementation, but overall it wasn't great

jauntywundrkind 11mo ago
Extensible, extense thineself.
ezst 11mo ago
> my experience with XMPP is that was not as solid as other solutions, including closed source ones. Considering that WhatsApp is essentially an old/non-federating fork of ejabberd (from where this blog post originates), I think XMPP is doing alright in that regard.
- greatgib 11mo ago
  Looking at how many years ago the fork open, you can easily guess that the protocol doesn't look anything at all like XMPP.
  - ezst 11mo ago
    For sure, it got continuously refined for WA-specific needs over the years, but XMPP very much still is there, lurking in the shadows: https://www.sciencedirect.com/science/article/abs/pii/S1742287615000985 https://www.sciencedirect.com/science/article/abs/pii/S17422...
RadiozRadioz 11mo ago
"not as solid" - please explain.

up-n-atom 11mo ago

Is it really a question about processing performance though? I’ve always assumed it was about bandwidth and latency… Communication protocols don’t need to be human-readable because tooling has always provided that at a higher level. A binary protocol just as a text protocol like S-expression or the divine simplicity of IRC is just as digestible when documented. And there are better facilities to have extensibility regardless. I think we can all agree it’s as much a failure as a success if we’re still talking the same points 25 years later.

zamalek 11mo ago
XML compresses really well.
- dafelst 11mo ago
  Because it contains a ton of redundancy
  - zamalek 11mo ago
    Exactly? What's your point? Things have to be low entropy/contain a lot of redundancy in order to compress well.
    - dafelst 11mo ago
      If it were a more compact format, it is likely both the uncompressed AND compressed sizes would be smaller. By your logic, if you 10x'd the length of the XML tags in XMPP then it would be even better since you you would get an even further improved compression ratio. To be clear, I don't have a problem with XML in XMPP since it is negligible overhead, but "it compresses well because it is full of redundancy" is not the argument that should be used to justify it.
      - zamalek 11mo ago
        That's a strawman. I am not arguing that we make the tag names longer, I am arguing that there is little benefit to a more concise format. If you are so bandwidth constrained that deflated XML won't do, then I doubt deflated JSON would be good enough either (and that exists anyway, Matrix).

RadiozRadioz 11mo ago

To take a slightly cynical view, but a view I honestly believe in, on the want to switch to JSON: XML looks old, most programmers have shallow opinions and chase new things. It's not parsing performance, computers are plenty fast for text IM. It's not bandwidth, the difference between JSON and XML is negligible after compression. It's not developer ergonomics, any sane programmer is using a library that abstracts either format. It's not compatibility with the domain, as XML wins for XMPP due to namespaces. The answer is that XML looks old. New programmers (half of all programmers have less than 5 years of experience) grew up in a world of JavaScript where XML was "legacy" since the day they arrived. In reality it's kept working fine, while the volume of software has increased around it naturally using the trendy tools. They've not looked back to understand why it was made or why it has merits, it's already got negative connotations and they're caught up in the new stuff. The new stuff has merit too, that is why a programmer is wise to respect both. Also, what use is a stable and mature XML ecosystem when you can earn big nerd points by reinventing XPath for JSON the 5th time?

rented_mule 11mo ago
XML and JSON only started about 5 years apart (1996 vs. 2001). I think XML's adoption was more broad more quickly, so the gap felt a bit longer than that (XML was a core part of my jobs from 1998-2007 and JSON ever since). I think more of what makes XML look so much older is the fact that so many new projects have been picking JSON over XML for 10-20 years now, and that's why younger folks have seen much more JSON than XML. My software engineering career started long before either, and I have used both extensively. While I don't think that it makes sense for most well established projects to switch, just as rewrites often don't make sense, I would almost always pick JSON for new projects. Your points are valid, but one part of the ergonomics that you didn't mention is that it's so much easier for humans to read and write JSON, thereby speeding up development, debugging, testing, etc.

zzo38computer 11mo ago

I agree that it should not use JSON. I think it would be better to use DER (or SDSER if streaming is needed) rather than XML or JSON, but that is just my opinion. However, if the existing protocol already uses XML, then that is what it will be, but the new one perhaps would not use XML.

soul_grafitti 11mo ago

Here's a thought - the thing that will ultimately doom XML, and perhaps JSON as well, will be the extra expense XML incurs when being tokenized for LLMs.