Modern means: "we analyzed all bad things about the thing and fixed many of them". Paradigm in "modern"-term is "more time - better solution". So "modern" - many time passed.
Bad for whom exactly?
For example, here it seems today's usecase was a "SMS-like mobile messenger", so they are deprecating stuff such as resources, priorities and presence notifications. WHY? My use-case as is the entire of my network is multiple devices, so resources AND priorities are a must.
So rather than "modern XMPP" this looks like "how to use XMPP to build a SMS-like messaging program for mobile phones". Now it's clear who is the target of the document and you avoid a weasel term like "modern" which also annoys every other consumer of the protocol.
You're right. I take responsibility for the name, but naming things is hard!
As for the focus, you're right, there is a bunch of advice that is specific to this class of personal messaging apps. As time, resources and interest allow, I would like to grow it to document other "profiles" of XMPP as well. For example the Slack-like "team chat" use-case, or even IoT.
If you're using XMPP in a particular domain and you feel it would benefit from documentation like this, PRs are absolutely welcome. It's in scope.
I think it's fair to describe the SMS-like mobile messenger as the modern goal of XMPP if that is in fact what people are using. The goal here is to get broader adoption for the protocol, and the only way to do that is to make it easy to deploy and use for a mass-market audience that expects certain things already.
AshamedCaptain|4 years ago
So rather than "modern XMPP" this looks like "how to use XMPP to build a SMS-like messaging program for mobile phones". Now it's clear who is the target of the document and you avoid a weasel term like "modern" which also annoys every other consumer of the protocol.
MattJ100|4 years ago
As for the focus, you're right, there is a bunch of advice that is specific to this class of personal messaging apps. As time, resources and interest allow, I would like to grow it to document other "profiles" of XMPP as well. For example the Slack-like "team chat" use-case, or even IoT.
If you're using XMPP in a particular domain and you feel it would benefit from documentation like this, PRs are absolutely welcome. It's in scope.
selfhoster11|4 years ago