jdev - 2021-07-06

hi

hi

Hey all. What are your thoughts on this (https://news.ycombinator.com/item?id=2069810) and this (https://harmful.cat-v.org/software/xml/)? [Genuinely Asking].

ConcernedPerson, I think this was what prompted for the creation of this page: https://xmpp.org/about/myths.html

FWIW this person is pasting this into a bunch of XMPP-related channels

Link Mauve: thats actually a good read. thanks for sharing!

Ah, I hadn’t seen.

ConcernedPerson, you shouldn’t post the same message in five different rooms, it’s bad practice.

> XMPP is what I cite when I try to explain the "XML mindset". It leads to bad things. It leads to ridiculous overengineering through layered complexity. It leads to a client/server ecosystem where each implementation speaks a different dialect because it's nearly impossible to get the protocol right. Completely agree, but also it's not as if there's anything better and it's already pretty widely adopted so even if there was something better XMPP might still be worth using.

that multi-muc copypasta sounds like a collective invitation to lose time debunking already debunked claims

Sam: Good point.

Link Mauve: I just wanted to gather thoughts from as many people as I can. Some happen be across in those rooms.

Sam: I’m not even sure I agree that ‘riduculous overengineering’ is due to XML (indeed, we cut out large amounts of XML because it would be overengineered), that we don’t use our overengineering, or that optional features are because of XML :)

Not due to technical stiff about xml perhaps, but we definitely inherited 'xml culture'

I’m not convinced. I imagine most XMPP devs had little to do with XML before they started working with XMPP (I hadn’t touched it in anger until then, at least). ✏

I don't think whether you were involved in xml or not matters, you can still pick up the xml culture of "everything has to be over engineered and be xml even if it makes no sense"

I’m not convinced that another encoding would make a significant difference, really, if we ended up still allowing unnegotiated arbitrary extension.

Obviously if you don’t want extensibility, other things are much simpler.

You have data. You squeeze it into a form that fits the data model of whatever your serialization is. You throw it at the wire. You go on with your life.

Except when your serialization format has multiple ways to handle data and it's hard to pick between them, it's so complicated you have to restrict the format to a sane subset of it thereby resulting in more bugs when various things implement that incorrectly because you can no longer rely on the underlying serialization implementation.

Pick a way, write it down, slap the label "XEP" on it and hope it helps.

Anyways, it's too late to go back on XML, I'm just saying that we need to admit we have a problem and that it's extremely difficult to implement even a small subset of XMPP for a simple chat service and we need to actually think about that instead of just pretending it's not a problem.

It's not so bad. I've seen worse. There are other problems that warrant more attention than XML vs JSON rehash #5647

I've seen worse too, but that doesn't mean that we don't have a problem.

I don’t know that it’s really much of a problem. The amount of time I (or any of the teams I’ve worked with) have spent dealing with problems introduced by XML is tiny compared to all the other things that matter.

I really don't think use of XML in XMPP is a problem that warrants the amount of noise that was just created.

Let's do a rewrite in $flavour_of_the_month, and all our problems will be solved

But let me tell you about mod_rest/jsonmap

With all this said, I *do* think there’s value in jmap-mpp or whatever one would call an IM mapping of XMPP into something JMAP-ish. But not because of it being JSON-vs-XML, but because of it being state-vs-stream.

CBOR!

...encoding rules

(State vs stream is an ugly way of expressing what I mean, but hopefully it’s not that unclear)

Zash: M-Link uses CBOR...

Hi, i have heard of cbor!

Again though, none of this was even about JSON vs. XML except that I let myself get distracted. It's about the XML mindset that we've inherited and everything being overengineered and having 4 different ways to do every thing.

Welcome to any large system

It’s not like even single-entity-controlled systems tend to remain pure once they reach a certain size.

Large systems can be complex, they don't have to have all the overengineering and bad choices we put into everything.

Sam, could you define "XML mindset"? I still don’t understand what you mean, is it the use of namespaces? elements? attributes? schemas?

Everything must be XML all the time even if it doesn't make sense (ie. XML Schema, rewrite existing things to have an XML encoding, etc.), multiple ways to do everything (some things are attributes, some are elements), and just generally overengineering everything and inserting a million edge cases even when it's not necessary.

Maybe sumarized it would be "more features are good and optional bits can't hurt"

XML schema is… necessary? I mean, json schema is not much more readable, and we need a formal way of expressing the payloads anyway

(the one criticism that I would put on the xml schemas is that they are underused, if anything)

A schema may be necessary, and I agree they're underutilized. XML Schema is just an example of something that could have been good that the XML community turned into an overengineered mess. I don't care if JSON schema is far worse, that doesn't make what we do good.

There are also at least 3 XML schema languages that I'm aware of, so that also seems to be an XML community mindset thing we've adopted.

Anyways, fine, ignore that particular example then, focusing on one tiny part of the argument isn't helpful. Even if you're completely right and XML schema is fine that doesn't change the point I was making.

I don't understand how the problem is related to xml. Handling forward and backward compatibility is hard and requires a lot of planning ahead for things that may never happen, but I've seen that done with clearly non-xml things, like C++ software

(or even the C++ language itself)

To me it looks like a necessary evil if you want a standardized thing with many implementations of it

Also thinking about the 3 or 4 RFCs documenting http cookies, none of which document what's actually done in the real world by servers and browsers

It's not related to XML. It's related to a mindset we inherited from the XML community.

Well,if the alternative is a "move fast and break things" mindset I think I prefer the current one

It's not.

I think this mindset doesn't even exist, so I don't know how to participate in a discussion about solving it :)