4 ms·
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 hu
by up-n-atom 10mo 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 10mo agoXML compresses really well.
- dafelst 10mo agoBecause it contains a ton of redundancy
- zamalek 10mo agoExactly? What's your point? Things have to be low entropy/contain a lot of redundancy in order to compress well.
- dafelst 10mo agoIf 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 10mo agoThat'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 10mo agoYour 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.
- zamalek 10mo agoWhere in my original argument did I suggest making the tags longer?
- dafelst 10mo agoYour argument was that XML compresses really well, which indicates that compression ratio is your evaluation metric. I just suggested a simple way to improve your metric. My position is that compression ratio is a largely meaningless metric in this instance, so using it as a method for justifying the use of XML (as inferred from "XML compresses really well") is also meaningless. That does not translate to "XML is bad for XMPP", I actually think it is fine, it means "XML compresses really well" doesn't add anything much in the way of justification. I've spent way too much time on this thread already, so take what you will from it, it is all you from here on out, I am done here.
- zamalek 10mo ago"By your logic" is usually a canary for strawman, and it's needlessly combative on top of that. Best to step back and reconsider if you find yourself penning that. The only thing I was saying was exactly what I said, within the context of XMPP, XML compresses really well - I was reinforcing the parent comment. How that relates to metrics in other contexts wasn't what I was talking about at all. I generally avoid XML nowadays, and so your argument with me isn't something I would dedicate thought to in the first place. I see no point in taking anything from this nonsense.
- ezst 10mo agojust posting this here: https://www.isode.com/whitepaper/operating-xmpp-over-hf-radio-and-constrained-networks/ https://www.isode.com/whitepaper/operating-xmpp-over-hf-radi...
- up-n-atom 10mo agomonetization makes for a conceiving argument so I will leave this here as well https://www.wwt.com/case-study/tactical-chat-solution-navy/ https://www.wwt.com/case-study/tactical-chat-solution-navy/