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. > 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. 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* :) > 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!). > 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. > Myth Four: XMPP is unreliable without a bunch of extensions. > Myth Five : XMPP is unsuited to the web. These myths I have explained in 1-3. Yes, you need to use many extensions (and write themself new too), and e.g. session restoring is the same XMPP problem for Web as for mobile.
