[Standards] XMPP Myths
dave at cridland.net
Thu Aug 27 16:13:14 UTC 2015
On 27 August 2015 at 16:14, Vitaly Takmazov <vitalyster at gmail.com> wrote:
> > It's here: http://wiki.xmpp.org/web/index.php?title=Myths
> I don't understand where is the proper place to comment it, so I will
> comment it here.
Thanks for taking the time to comment; it's really appreciated.
FWIW, most of these hypotheses were drawn from one particular FAQ which
detailed why XMPP was terrible and you should use their stuff instead -
that is, I didn't make them up because they were easier to knock down this
> > XMPP is XML, so it's too slow.
> Yes, many novice developers saying exactly the same, but the problem is
> much deeper:
> *development with* XML/XMPP is *much slowly* than with JSON.
> Imagine you are a novice developer, who is not familiar with XML/XMPP but
> wants to build messaging app: almost every programming language and
> framework have a) built-in HTTP server, b) language structures, like
> dictionaries and arrays, which perfectly maps to JSON, and it is enough to
> describe his own Message class with all required fields, serialize it to
> JSON, send it to server app and deserialize it to its own language
> structure. So he get the whole client/server app just easy and quick.
This is all true, but none of it will get you interoperability between
sites, and you'll also have to reinvent your security from scratch again.
JSON works as an ad-hoc tool, of course, very well, for all the reasons you
list - but it's considerably less useful for building an interoperable
Of course, I'm not saying people should never use JSON either - and indeed
to could easily put JSON directly into an XMPP stanza without any problems
if you wanted.
> But with XML/XMPP: you have no a) easy to use development XMPP server
> incomplete), b) good XMPP library (in 99% cases you need to go deep into
> XML and add a new experimental XML namespace, well, I will explain it in
> Myth 2 and 3).
> So, with HTTP/JSON - developer only need to know his %language_of_choice%
> and all job will be done with familiar instruments. With XML/XMPP - he need
> to know: XML(and especially namespaces), network ifrastructure - DNS setup,
> XMPP server (ejabberd, openfire, prosody) and setup, strange
> non-mainstreamed languages like Erlang and Lua, to extend server to fit his
> needs, and many other problems. So, JSON - is *faster* :)
You make an interesting point here - XMPP is "production-only" in a lot of
ways - it's actually harder to setup a quick and dirty XMPP server than it
is to set one up for production. I'm not sure how to address that, but it's
a very valid point.
On the other hand, writing a component should be pretty easy in any
language, and if it's not, that's a problem. Also, I, too, have misgivings
about the use of novelty languages in XMPP; despite Lua being pretty easy,
I do much prefer something sensible. (And Erlang always looks like someone
was snorting Perl and sneezed to me).
That said, the servers do work; I can't complain there.
> > Myth Two: The baseline is minimal, therefore XMPP is useless.
> The problem with "XMPP baseline" is the following: RFC6121 is *not enough*
> to build *modern* messaging app. I will show only *one* example: RFC's
> <message /> have no widely used IM fields like "delivered" and "read", and
> there is no widely adopted XEP with these fields. XEP-0333? There is no
> libraries/clients/server support of it! So, XMPP baseline is *useless*: you
> need to study all XEPs, find namespace with required extended message
> fields (remember, you already need to understand XML namespaces? There is
> no such problem with JSON!), and add support of it to used "XMPP baseline"
> library (your programming skills now required to be 10x strong!).
RFC 6121 isn't enough to build even a very basic messaging app, though -
and that's by design.
If we used JSON, we'd still have namespacing somehow, and the choice of
JSON model would not always fit your purposes - in effect, the JSON would
be equally as ugly as the XML.
As a final note, the nice thing about having all these specs is that a
great many people have carefully thought through how these might work most
efficiently, and where the problem areas might be.
The rest of these comments, though, I largely agree with - there's been
talk of putting together both a new profile XEP, listing the things any
"modern messaging app" should support, and also putting together a bunch of
sensible tutorials. I think you're underlining how important those are.
> > Myth Three: It's too bandwidth-inefficient for mobile.
> > The hypothesis: XMPP stanzas are just too verbose to work on mobile.
> No, your hypothesis is wrong again! XMPP is too inefficient on mobile,
> because it was not designed with mobile connection in mind.
> How typical mobile app works: connecting to his server and authenticating,
> storing his auth token, sleeps forever in background - and continue to work
> every time user open app again. Server can invite user again with
> phone-vendor's "push notifications". That's all. There is no battery and
> bandwidth-drain in background at all.
> How typical XMPP app trying to work: he trying to maintain persistent
> socket connection! And every TCP disconnection is fatal - you need to
> authenticate again. And you will just leave all your MUCs and spam all
> participants with presences! And there is no XEPs to fix it. XEP-0198? 300
> seconds to restore session? It is NOT a mobile scenario.
There's also a whole heap of work on using the mobile network's push
notifications; but as I say, my Solitaire app uses more battery than my IM
app on my phone even without such a spec. And I don't even play solitaire
that much. For the record, my server doesn't support '198 resumption
either, so I pay the full penalty for losing the connection.
Once established, that TCP session can stay up, and silent - no battery, no
bandwidth drain - for hours.
Also, I'm not sending any traffic through Google's servers.
I know you're stating the received wisdom here, but I just don't see it
reflected in reality.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards