[Standards] XMPP Myths

Dave Cridland 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:

> Hello!
>
> > 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
way.


> > 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
extensible protocol.

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
> (there are some python/javascript samples, but they are buggy and
> 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.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150827/fb9c5ea9/attachment.html>


More information about the Standards mailing list