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.
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).
However, on your latter point, I am in full agreement.
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.
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.
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?
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.
hasperdi•2mo ago
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•2mo ago
ezst•2mo ago
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•2mo ago
ezst•2mo ago
RadiozRadioz•2mo ago