What proportion of their clients used it? Was it worth it to support such a horrible protocol?
XML inside XML inside XML inside XML inside
Edit: PSYC outlines XMPP problems pretty well. I wish PSYC was more prevalent.
Impressive, in a way.
The point isn't text → simple (semantics), it's text > binary (syntax).
Complexity is mostly a property of semantics, text vs binary is about the syntax used to convey those semantics. For the same semantics, text is easier to debug than binary. That's all.
XMPP bad. Binary XMPP worse. Etc.
If anything, this should be a lesson for consumers and to learn how to not give that much power to a couple of organizations.
Why.
What matters is how useful users think it is. Whether developers think the code is beautiful is less important for adoption.
And your second paragraph misses the point: it's not about one of the factors, it's about balance between them. In this particular case, the amount of users who prefer XMPP doesn't seem to be big enough to counter the pain of supporting it.
Wow, I can easily imagine much better interfaces. In fact I don't even have to imagine - Mercurial is way nicer.
What I really liked was the very friendly and usable command line interface, out of the box shortcuts (which I now emulate in my .gitconfig), clear help pages. It was a bit slower than git for enormous projects but it worked wonderfully for me.
More familiar because it was essentially subversions interface made suitable for a dvcs.
Worse for lacking (or requiring plugins for) features like the index, commit amending, rebasing, lightweight branches, etc.
MSNP (older versions):
FLN user@example.com
:nick!user@example.com PART #channel
<message
from='juliet@capulet.com/balcony'
to='romeo@shakespeare.lit/orchard'
type='chat'>
<thread>act2scene2chat1</thread>
<gone xmlns='http://jabber.org/protocol/chatstates'/>
</message>
NFY PUT 268
Routing: 1.0
To: 1:mypassport@hotmail.com
From: 1:en-cn@hotmail.com
Reliability: 1.0
Notification: 1.0
NotifNum: 0
Uri: /user
NotifType: Partial
Content-Type: application/user+xml
Content-Length: 50
<user><s n="IM">
<Status>FLN</Status>
</s></user>
A user going offline would be:
<presence from="juliet@capulet.com/balcony" type="unavailable"/>
And their XML parsing were quite limited.
But it's really very tricky to get a good user experience with it and the protocol is just not at all fun to work with. If it would not be the darling of the open source community it would not have gone far.
When I think of something super complex that's SOAP (where you can literally write the same call in multiple different and server-incompatible ways), and XMPP is nowhere close.
As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON (although possible with YAML or ASN.1, and doable with implementing some format on top of JSON). Most chat protocols just don't allow to implement arbitrary extensions. E.g. you want your chat service to have a concepts of, say, hats¹ for participants — with IRC the best you can do is to run a HatsBot or make a custom DCC protocol. With XMPP you just decide on a schema and put your stuff with a custom namespace (then if it's something useful for everybody, file a XEP). So, while XML may be not best format, I think it absolutely it made sense.
___
¹) I just wanted something silly. So, I thought of Team Fortress-style hats.
So even ignoring XMPP's intrinsic complexity, it's based on XML. XML is impossible to use securely out of the box without severely tweaking the parser. XML entity bombs, gazillion of different charsets you might encounter, stack exhaustion due to nesting of namespaces or elements in places you don't expect etc.
The main reason many of these issues are not better known is because it did not get popular enough that people bothered exploiting it.
> As much as I don't like XML (and I do), it allowed XMPP a great amount of extensibility that's just not possible with simpler/non-extensible formats like JSON
You do not need schemas and namespaces to be extensible.
Nope, they all well-known and were exploited (I saw all of this stuff, in vivo). Except for charsets — XMPP had limited charsets right from the beginning, so it's not applicable.
XML absolutely has a lot of issues, I'm with you on this. I've just pointed it made some sense.
> You do not need schemas and namespaces to be extensible.
Schemas - no. Namespaces - I'm sure they're necessary. Even if the namespaces are just prefixes of JSON dictionary keys or custom ASN.1 OID, they're still namespaces (and XML namespaces aren't really different here, just a URL-to-short-prefix maps and colon-separted prefixes). Otherwise it will end up very messy.
I mean, nobody wants a logic like "that's a message from Foobar 1.x client, so 'x-typing' property here means typing state, not use of monospaced typewriter-style font like Bazbaz 2.x software does." And that's inevitable without namespaces.
* It's designed to accommodate as many use-cases as possible with a variety of actors chiming in with their own requirements
* a tiny core that doesn't do a lot, and a gazillion extensions
* when you want to implement a software in XMPP world, you don't have a clear view on what extensions you need to implement and what extensions are nice-to-have (other than word of mouth)
* corollary: extensions can move fast, some are new, some die, but the perception doesn't change as fast, so old habits remain for a long time (cue "PSYC said XMPP sucks") and softwares don't evolve to accommodate later improvements
* second corollary: since the bulk of what makes XMPP useful is defined in extensions, as a user you don't know which client or which server you should pick
* by design there's no reference implementation, which means you don't really know where to start
* it's XML, and XML doesn't exactly play well with recent languages (you won't write XML itself so you'll use what your language gives you, but it doesn't always map very well with XML)
To summarize, XMPP can do everything, provided that you know your way. If you don't know anything you will most likely be disappointed by your first experience, as a user.
What we really lack is a bit more guidance: the XSF (XMPP Standards Foundation) is only interested in making sure the standard is properly specified, that demands are met appropriately. It's a huge huge job, but for a community of developer it's not enough. There has already been talks to update the suite of extensions that are considered almost-mandatory in a modern IM software; it would also be really awesome to have a reference implementation for each usage (ie one server, one IM client, one VoIP client, one microblogging client, ...) because, like many others, I find tangible code we all agree on to be of very high value.
I fear that other protocols will be created, they will all (or at least a good part) die, and in the end we'll have XMPP, standing there in the waves of protocols, chugging along quietly. People will be mocking it not because it doesn't work, but because they don't understand it (and that will be a fault with XMPP, not with people, because it will remain extremely complex)