41
edits
Difference between revisions of "Myths"
Jump to navigation
Jump to search
→Myth Three: It's too bandwidth-inefficient for mobile.
| Line 50: | Line 50: | ||
On mobile, the most concerning cost is the stream startup time - because it uses a sequence of round trips - but extensions such as XEP-0198 can help reduce this substantially. | On mobile, the most concerning cost is the stream startup time - because it uses a sequence of round trips - but extensions such as XEP-0198 can help reduce this substantially. | ||
And as I said before, XMPP is a NAK protocol - traffic doesn't get acknowledged in the success case normally, only on error. If you examine protocols specifically designed for low-bandwidth, you'll find the same design prevails. | |||
Compare this with any protocol that is based on JSON over HTTP - HTTP/1.1 is an amazingly verbose protocol, so the overhead of each transaction is going to be quite astonishing. HTTP/2.0 may help with this, of course. | Compare this with any protocol that is based on JSON over HTTP - HTTP/1.1 is an amazingly verbose protocol, so the overhead of each transaction is going to be quite astonishing - and every HTTP API command must be acknowledged with a response. HTTP/2.0 may help with this, of course, but the overhead doesn't vanish entirely. | ||
XMPP has been used over mobile for years, and while Push (XEP-0357) is relatively new, that's in part because mobile platforms other than Apple's simply haven't required it - Android clients work fine without, for example - and as a community we've been working with mobile as a focus for a number of years (see XEP-0286). | |||
== Myth Four: XMPP is unreliable without a bunch of extensions. == | == Myth Four: XMPP is unreliable without a bunch of extensions. == | ||