4 ms·
> too extensible I don't see how it's a problem, except for: > with too few guarantees in interoperability ...Which indeed makes life harder. As mentioned el
by defanor 5y ago
> too extensible
I don't see how it's a problem, except for:
> with too few guarantees in interoperability
...Which indeed makes life harder. As mentioned elsewhere in the discussion, there are compliance suites, and capabilities and feature discovery, but the clients are indeed quite diverse, and sometimes it's hard to know what to expect from them.
> XML is not a good serialization format
I personally find it more suitable than JSON for many purposes, including extensible IM, for a couple of reasons: namespaces help to avoid conflicts, while the data model itself is more convenient for general data encoding since it's straightforward to encode sum types in XML (where a tag corresponds to a constructor), unlike in JSON (where there's a few ways to achieve it, though with JSON-over-HTTP that part is usually only done on the top level and goes into HTTP query). Maybe I'd prefer s-expressions to XML for an IM, but not JSON.
> and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS).
I wouldn't call that one "exotic": STARTTLS is used by a few other common protocols, and allows for opportunistic TLS; easily usable with common libraries (OpenSSL, GnuTLS) too. There's XEP-0368: SRV records for XMPP over TLS [1] for direct TLS connections though.
[1] https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensions/xep-0368.html
- azalemeth 5y agoI've never understood why XML gets so much hate outside of the context of the browser. Yes, it's verbose but fully featured parsers are everywhere and it seems far easier to include a random (base-64'd) binary blob in place if required as opposed to JSON. This is an area I know little about -- I'd love someone more knowledgeable to educate me.
- IanCal 5y agoI think it's partly down to being exceptionally verbose for simple tasks. Dealing with extra empty text nodes, namespacing, etc. JSON for most simple use cases is just "dump kv, load kv". I'm not sure I understand the issue with base64 in JSON? Have I misunderstood the point there?
- Sebb767 5y agoAdditionally, XML, with its nesting and attributes, doesn't map particularly well to a specific programming construct. Also, you can represent an object in a lot of ways. JSON, on the other hand, is dead simple: You have your list/array, dict/object and four value types. Representing JSON in your favorite language is straight-foward and how the serialized version of a hierarchy looks is immediately obvious in nearly all cases.
- progval 5y agoDepends on the language. XML maps nicely to C/C++/Java/Rust/... structures, that you can generate from a schema at compile time. Dealing with arbitrarily typed arrays and objects is painful in some languages because you need to use variants and dynamic-cast every access to the document.
- floatboth 5y agoHow is it "nice" when any struct member could map to either an attribute or a child element? XML is a markup language. It's in the name even. Trying to use it for serialization is weird.
- progval 5y agoYou declare which one it should be in the schema (used to generate the struct and its (de)serialization code) > XML is a markup language. It's in the name even. It can be used for markup, but isn't limited to that.
- Sebb767 5y agoThat's exactly the problem I was going for - feature richness is the enemy of simplicity. The fact that you need to read a schema (and learn one of the schema languages) makes starting out with XML just much harder than JSON.
- djur 5y agoUnbounded extensibility is a great way to get adoption of a standard, in the sense that a lot of products will say "Fully $standard Compatible!" in their marketing materials. It is a bad way to ensure that the standard actually means anything outside the marketing materials.