ConcernedPersonHey 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].
Link MauveConcernedPerson, I think this was what prompted for the creation of this page: https://xmpp.org/about/myths.html
MattJFWIW this person is pasting this into a bunch of XMPP-related channels
jubalhLink Mauve: thats actually a good read. thanks for sharing!
Link MauveAh, I hadn’t seen.
Link MauveConcernedPerson, you shouldn’t post the same message in five different rooms, it’s bad practice.
Sam> 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.
mathieuithat multi-muc copypasta sounds like a collective invitation to lose time debunking already debunked claims
ConcernedPersonSam: Good point.
ConcernedPersonLink Mauve: I just wanted to gather thoughts from as many people as I can. Some happen be across in those rooms.
KevSam: 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 :)
SamNot due to technical stiff about xml perhaps, but we definitely inherited 'xml culture'
KevI’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).✎
KevI’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). ✏
SamI 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"
KevI’m not convinced that another encoding would make a significant difference, really, if we ended up still allowing unnegotiated arbitrary extension.
KevObviously if you don’t want extensibility, other things are much simpler.
ZashYou 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.
SamExcept 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.
ZashPick a way, write it down, slap the label "XEP" on it and hope it helps.
SamAnyways, 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.
ZashIt's not so bad. I've seen worse. There are other problems that warrant more attention than XML vs JSON rehash #5647
SamI've seen worse too, but that doesn't mean that we don't have a problem.
KevI 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.
ZashI really don't think use of XML in XMPP is a problem that warrants the amount of noise that was just created.
MattJLet's do a rewrite in $flavour_of_the_month, and all our problems will be solved
ZashBut let me tell you about mod_rest/jsonmap
KevWith 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.
Kev(State vs stream is an ugly way of expressing what I mean, but hopefully it’s not that unclear)
KevZash: M-Link uses CBOR...
nepheleHi, i have heard of cbor!
SamAgain 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.
MattJWelcome to any large system
KevIt’s not like even single-entity-controlled systems tend to remain pure once they reach a certain size.
SamLarge systems can be complex, they don't have to have all the overengineering and bad choices we put into everything.
mathieuiSam, could you define "XML mindset"? I still don’t understand what you mean, is it the use of namespaces? elements? attributes? schemas?
SamEverything 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.
SamMaybe sumarized it would be "more features are good and optional bits can't hurt"
mathieuiXML schema is… necessary? I mean, json schema is not much more readable, and we need a formal way of expressing the payloads anyway
mathieui(the one criticism that I would put on the xml schemas is that they are underused, if anything)
SamA 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.
SamThere 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.
SamAnyways, 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.
pulkomandyI 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
pulkomandy(or even the C++ language itself)
pulkomandyTo me it looks like a necessary evil if you want a standardized thing with many implementations of it
pulkomandyAlso 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
SamIt's not related to XML. It's related to a mindset we inherited from the XML community.
pulkomandyWell,if the alternative is a "move fast and break things" mindset I think I prefer the current one
MattJI think this mindset doesn't even exist, so I don't know how to participate in a discussion about solving it :)