[up-n-atom]

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.

[ezst]

just posting this here: https://www.isode.com/whitepaper/operating-xmpp-over-hf-radi...

[up-n-atom]

monetization makes for a conceiving argument so I will leave this here as well https://www.wwt.com/case-study/tactical-chat-solution-navy/

[zamalek]

XML compresses really well.

[dafelst]

Because it contains a ton of redundancy

[zamalek]

Exactly? What's your point? Things have to be low entropy/contain a lot of redundancy in order to compress well.

[dafelst]

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]

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).

[dafelst]

Your argument was initially stated as "XML compresses really well", not "there is little benefit to a more concise format".

However, on your latter point, I am in full agreement.