I used it on my desktop. You can call XMPP horrible, it still worked without any problem. Much better than having a browser tab dedicated for Facebook.
With respect, you're only one person out of billions. Individually, I used it as well. And (as far as I heard), XMPP sucks for developers to implement and support, not necessarily for users themselves.
The technical part doesn't really matter. The problematic part is that Facebook (and Google) took a page from old Microsoft and applied "Embrace, Extend, Extinguish" to the one alternative we had for an open and federated messaging platform.
If anything, this should be a lesson for consumers and to learn how to not give that much power to a couple of organizations.
Because lots of things flourish despite not being the most beautifully designed piece of technology. Git survives despite its widely-derided UI, email proliferates despite spam, and Linux is dominant despite having a less beautiful kernel than BSD.
What matters is how useful users think it is. Whether developers think the code is beautiful is less important for adoption.
Yeah, these things are mostly true (apart from git, which I think has the best possible interface for a VCS), but I don't understand why did you suddenly switch from a question about a decision by a particular company to a question of wide adoption of technology by a community.
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.
Shame mercurial didn't catch on. I started learning DVCS' with mercurial, back when they were still a new concept, and git wasn't very good (this is an understatement, git was horrible back then).
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.
Git didn't have any of those things either except "lightweight branches". It wasn't until 2006 or so that git grew a reasonable commit command. Before then, people relied on tools such as cogito in order to get work done.
Yeah as much as I appreciate the concept of XMPP, I find it unlikely that the average person cares about that sort of stuff. Of course, I'm limited to the people I know, so maaaaybe I'm mistaken, but if you think about the average Facebook user (Joe Smith, has 600 friends he barely knows, likes to quote songs in his statuses), what are the odds they would NOT want a dedicated app or tab?
"The tech folks", "text based therefore simple", suggesting anybody ever used XML and simple in one sentence, implying http would be better off binary, … how can such a small comment pack such a misleading punch.
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.
I agree with the browser tab, this is annoying. I've tried alternatives for Mac: Current and Goofy (basically wrappers around the conversation page), but they're both quite unstable.
So far the best option was to keep another tab open, just switch from messenger.com to see only conversations without all the FB feed
There are multiple pain points with the way the XMPP protocol is "organized":
* 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.
Does xmpp handle the case where you've read a message on another client and you want all clients to see it as read? Seems like possibly an argument for centralized storage
At this point I don't think there is a huge benefit in starting another protocol. There are problems with XMPP, but IMHO they're more in how it is organized than in the protocol itself. XMPP has surveyed a huge chunk of the space, it has seen where things are difficult and proposed a solution for that. It is in use by many entities already, with many different use cases (one of the later extensions (https://xmpp.org/extensions/xep-0365.html) is to use XMPP over radios with atrocious conditions: latency in minutes, throughput as low as 75 bits/s. Also, for some reason XMPP has seen some success in military), it has all the benefits of being an approved IETF protocol (one of which being that it will still be here in 10 years, whatever happens). Sure, it's old stinky XML, but it's not like it's a brand new technology where little documentation exists. There are libraries in most languages already.
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)
As someone who implemented stuff for XMPP many years ago: it's a super complex, XML infested protocol that if implemented correctly can only result in a bad user experience. It gets a little bit better if you support only a subset of it (eg: you take away the federation aspect of it) and target a single server and assume you control all clients.
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.
It's not really complex on its own, just that a lot of developers used ad-hoc regexp-based parsers and made some assumptions (like hardcoded namespace names, say, some software really expected "x:" prefix and didn't care for "xmlns"es) when processing it. I absolutely admit (and don't like) a bad framing scheme — it would've been much better not as XML stream, but as TLVs of structured data — but that's manageable with streaming parsers, and otherwise I don't see why XMPP's core is super complex.
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.
> The main reason many of these issues are not better known
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.
That's what I read in a couple of blog posts in articles by people who implemented it. I can't bring the up right now, but after one minute in google, I found this conversation to be quite interesting: https://news.ycombinator.com/item?id=2069810
I think older MSNP and IRC are the best of all the IM protocols I've seen, and I've written clients for both. OSCAR (ICQ/AIM) is a binary format that doesn't look too hard to parse; I'd say it's still better than working with XML.
And yes, XMPP is extensible, so you might see such notifications with more content (e.g. the user can set an offline message), but the beauty is that not every client need implement support for that, which is handy if you're writing a thin client like a bot, or doing machine-to-machine communication. But every XMPP client will interpret the core meaning exactly the same: the user has gone offline.
Message size is important, but for low-bandwidth instant messaging is XML really bothersome? I mean it's not like you're writing your own XML parser or serialiser, is it?
The sad truth about XMPP is that a lot of developers actually did this (at least in early days). Maybe because a lot of readily available libraries weren't really compatible with XML streams and XMPP's idea of framing.
