On 27 August 2015 at 16:14, Vitaly Takmazov <[email protected]> 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.
