161–169 of 169 posts
Earlier quoted context omitted.
The writing was on the wall before that, though. WhatsApp was eating everyone's lunch and Facebook / Google wanted to move faster and own the messaging space.
WhatsApp didn't exist yet
Earlier quoted context omitted.
If everyone is using Conversations as their client, group chats work fine. Issues arrise when you introduce other clients into the mix ...
So Conversations has implemented a feature that isn't in the protocol, but important enough that when the feature doesn't work, users are turned off? Or it's part of the protocol, but design decisions lead to client interoperability problems? Maybe there's a third answer, but both of these are problems with XMPP.
Earlier quoted context omitted.
If everyone is using Conversations as their client, group chats work fine. Issues arrise when you introduce other clients into the mix ...
So Conversations has implemented a feature that isn't in the protocol, but important enough that when the feature doesn't work, users are turned off? Or it's part of the protocol, but design decisions lead to client interoperability problems? Maybe there's a third answer, but both of these are problems with XMPP.
I wanted to like XMPP, but I never did. It drowns developers in complexity so they never get around to solving anything interesting or useful. Bonus: I once discovered I had two of the main culprits for XMPP getting one of its worst misfeatures (lack of sensible framing) in the same room so I got to yell at them for it. XMPP was form over function. And it wasn't even pleasant form.
In a sense the problem with XMPP is that it is too simple. If you are willing to type some XML you can log into a server and have a basic chat session over a telnet session. Hence the requirement for extensions to do anything else. The alternative is to try to anticipate everything anyone would want to do with a protocol. That has problems as well. The XMPP approach is to accept everything and aggressively ignore eve…
Using XML framing in XMPP was the opposite of simplicity. (Sure it was simple in the sense that it required zero experience with actual implementation of protocols to arrive at the conclusion, but the result was something that was harder to implement properly).
It is "simple" for moronic, bad, implementations of the protocol, but it only complicates the situation when you need performance, quality and efficiency. It complicates it greatly. In essence, you end up having to write two parsers: a shallow framing parser and a deep parser.
And if you think you are going to get any help from the fact that there are lots of XML parsers: I've got bad news for you. There's lots of XML parsers that are meant to parse documents. Not millions of simultaneous, "endless" streams of data from dodgy clients.
XMPP is not good protocol design. It is brutally stupid protocol design.
(An irony is that right now there are several areas where you would want to use a messaging protocol for small devices. This ought to be the moment where a messaging standard had a chance to shine. And XMPP ends up being one of the least desirable protocols because so little care was taken in designing it)
Earlier quoted context omitted.
In a sense the problem with XMPP is that it is too simple. If you are willing to type some XML you can log into a server and have a basic chat session over a telnet session. Hence the requirement for extensions to do anything else. The alternative is to try to anticipate everything anyone would want to do with a protocol. That has problems as well. The XMPP approach is to accept everything and aggressively ignore eve…
Good protocols have a layered design where you deal with different concerns in a fashion that promotes simplicity, robustness and performance. For instance first the complexity in framing individual messages, then the way you represent the payload (on at least 2 levels), and then the semantics you can layer on top of that. Using XML framing in XMPP was the opposite of simplicity. (Sure it was simple in the sense that…
You obviously wouldn't use such a parser for XMPP. You would use a parser designed for the purpose. Very few people would ever have to even think about the issue, there are XMPP libraries available for pretty much any environment in existence.
Earlier quoted context omitted.
Good protocols have a layered design where you deal with different concerns in a fashion that promotes simplicity, robustness and performance. For instance first the complexity in framing individual messages, then the way you represent the payload (on at least 2 levels), and then the semantics you can layer on top of that. Using XML framing in XMPP was the opposite of simplicity. (Sure it was simple in the sense that…
> There's lots of XML parsers that are meant to parse documents. You obviously wouldn't use such a parser for XMPP. You would use a parser designed for the purpose. Very few people would ever have to even think about the issue, there are XMPP libraries available for pretty much any environment in existence.
XMPP also isn't usable for many new IoT applications where it should have had its opportunity to shine, but where there just isn't enough memory to deal with the ridiculous bulk.
But I do get that most developers don't really try all that hard. I mean, look at the resource usage of Slack. It is an application that does _nothing_ that requires CPU, yet it gobbles it up. It tells you something about the kinds of people that write chat applications today. Not exactly the sharpest tools in the shed.
Earlier quoted context omitted.
> There's lots of XML parsers that are meant to parse documents. You obviously wouldn't use such a parser for XMPP. You would use a parser designed for the purpose. Very few people would ever have to even think about the issue, there are XMPP libraries available for pretty much any environment in existence.
This is true for people who write applications. It is not true for people who would like to write servers and XMPP libraries that are somewhat efficient. XMPP also isn't usable for many new IoT applications where it should have had its opportunity to shine, but where there just isn't enough memory to deal with the ridiculous bulk. But I do get that most developers don't really try all that hard. I mean, look at the r…
Well presumably this hypothetical IoT application would have to support TCP/IP. Against that, a few hundred bytes of state table for the limited subset of XML required for basic XMPP would count for much.
Earlier quoted context omitted.
This is true for people who write applications. It is not true for people who would like to write servers and XMPP libraries that are somewhat efficient. XMPP also isn't usable for many new IoT applications where it should have had its opportunity to shine, but where there just isn't enough memory to deal with the ridiculous bulk. But I do get that most developers don't really try all that hard. I mean, look at the r…
>...the ridiculous bulk. Well presumably this hypothetical IoT application would have to support TCP/IP. Against that, a few hundred bytes of state table for the limited subset of XML required for basic XMPP would count for much.
Earlier quoted context omitted.
Except that messaging services are useless if the people you want to talk to don't use them. If all the people you want to talk to share your prioritization of freedom & privacy above everything else, then you're probably ok using a federated, self-run XMPP style messaging system. Unfortunately, for the vast majority of people, that just isn't the case. I would love it if I could use XMPP-based services to talk to ev…
> Except that messaging services are useless if the people you want to talk to don't use them. This applies to centralised/proprietary systems as well, including those 8 walled gardens that you use. When Slack was created, nobody was using it. When Signal came out, nobody was using it. Same with Telegram, Skype, Twitter and all the other centralised/proprietary systems. Some of those did manage to gain enough users f…