jdev - 2021-07-06

  1. sam


  2. jgart


  3. ConcernedPerson

    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].

  4. Link Mauve

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

  5. MattJ

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

  6. jubalh

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

  7. Link Mauve

    Ah, I hadn’t seen.

  8. Link Mauve

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

  9. 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.

  10. mathieui

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

  11. ConcernedPerson

    Sam: Good point.

  12. ConcernedPerson

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

  13. Kev

    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 :)

  14. Sam

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

  15. Kev

    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).

  16. Kev

    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).

  17. Sam

    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"

  18. Kev

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

  19. Kev

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

  20. Zash

    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.

  21. Sam

    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.

  22. Zash

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

  23. Sam

    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.

  24. Zash

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

  25. Sam

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

  26. Kev

    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.

  27. Zash

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

  28. MattJ

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

  29. Zash

    But let me tell you about mod_rest/jsonmap

  30. Kev

    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.

  31. Zash


  32. Zash

    ...encoding rules

  33. Kev

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

  34. Kev

    Zash: M-Link uses CBOR...

  35. nephele

    Hi, i have heard of cbor!

  36. Sam

    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.

  37. MattJ

    Welcome to any large system

  38. Kev

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

  39. Sam

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

  40. mathieui

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

  41. Sam

    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.

  42. Sam

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

  43. mathieui

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

  44. mathieui

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

  45. Sam

    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.

  46. Sam

    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.

  47. Sam

    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.

  48. pulkomandy

    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

  49. pulkomandy

    (or even the C++ language itself)

  50. pulkomandy

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

  51. pulkomandy

    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

  52. Sam

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

  53. pulkomandy

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

  54. Sam

    It's not.

  55. MattJ

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