|
1) XML really isn't that bad. Honestly. It can be (and is) parsed fast, without any schemas at all. The only thing you need to define about your namespace is the URI you're using. XMPP is not SOAP. 2) Wrong. RFC 6122 explicitly permits this. XMPP was designed for multiple devices, actually, but expectations changed over the past decade. Carbons (XEP-0280) does what people want now, and is widely deployed, in real clients and servers. Getting extensions to the "Experimental" state is easy, BTW - it's trickier moving them on from there because it's trickier to change them once they're widely deployed. 3) Bizarrely, you're mostly describing the client behaviour I have on every client I use. As for federation, that's what XMPP does. It doesn't do distribution, because doing that and getting autonomy for your security domain is hard (if not impossible). 4) Saying something is "objectively terrible" when it's clearly your opinion, and then rubbishing everyone who might hold a contrary one, is pathetic. The validity of your position is not helped by the XSF working on live documents for most of the time (the "Experimental" phase). Where it differs from the WhatWG is that specs move out of that phase once they're proven, and the documents become harder to change once they're Draft or Final, reflecting how hard changing all the implementations would be. The XMPP world sees people add extensions, try them out, and then move them to standards all the time. We see that from HipChat, Conversations, and plenty of others - it's a great way to work. Other folks like to get something to Experimental first, and that way get early feedback from the community. We think the way we work is a pretty good balance between stability and dynamism. 5) Absolutely not. That "X" stands for "Extensible" (I know, it was fashionable back in the '90's), and the XML namespaces you despise (and appear not to understand) mean that you can cheerfully slap whatever data you like in and alongside the standardized stuff. Trust me, the (many) IM services based on XMPP - and if it were as bad as you claim, that'd seem a poor choice - aren't refusing to federate because the OSS fans might not like it. Quite the opposite, actually. |
My mistake - it is a permitted option. Still, the standard (or at least RFC 3921) encourages servers not to - delivering to all clients is mentioned as the last MAY option, and only permitted at all if they all have the same priority (which given that clients like to do things like lower priority when you haven't been typing for a while, is very hard to achieve).
> XMPP was designed for multiple devices, actually
Be that as it may, it was a lot less usable in practice than any of the alternatives when used from multiple devices.
> Carbons (XEP-0280) does what people want now
Yeah, that's the extension I was talking about. Dated 2010 but I could swear I remember it being discussed in 2008 or earlier? Looks like it may, perhaps, have finally been standardized in 2015? Of course it's still an extension so you can't rely on any given implementation supporting it, though if you're saying it's widely deployed then that's a huge improvement over what I saw a couple of years ago.
> As for federation, that's what XMPP does. It doesn't do distribution, because doing that and getting autonomy for your security domain is hard (if not impossible).
Be that as it may, it leads to very poor UX. I can have one-to-one conversations with any of my contacts as though it were a peer-to-peer messenger, but as soon as I want to have a three-way conversation we have to pick a server and a room name and .... Heaven help you if you want to add a third participant to a conversation after you've started.