Difference between revisions of "Myths"

Jump to navigation Jump to search
2,165 bytes added ,  19:55, 10 August 2015
no edit summary
Line 82: Line 82:


The community developed this because TCP sessions are a lot less reliable over mobile — now a number of servers support it, and many mobile clients (particularly the Android ones) will use it if available.
The community developed this because TCP sessions are a lot less reliable over mobile — now a number of servers support it, and many mobile clients (particularly the Android ones) will use it if available.
== Myth Five : XMPP is unsuited to the web. ==
The hypothesis: XMPP is unsuited to the web because angle brackets and stuff.
The fact: XMPP has been successfully deployed to thousands of websites and has had pure Javascript libraries since its early days.
OK, I admit, I'm not a web guy, and I really don't understand the idea that because XMPP, like HTTP, isn't based around JSON, and because it instead uses angle brackets, like HTML, it should never be used on the web. Really, this bewilders me. XML is a web technology, after all, albeit it's not nearly as popular as it once was. Bindings like BOSH have been used for literally years to provide solid XMPP over HTTP, and libraries like Strophe.js handled a full XMPP stack in the browser sandbox amazingly well, due to the native (and fast - see Myth One) support for XML in the browser.
But I accept that many sensible people feel strongly that any self-respecting web-based API should involve passing JSON strings about, and the good news is that there's at least two libraries for you that present XMPP in exactly this way.
Stanza.io operates purely client-side, using the standard XMPP bindings for HTTP long-poll (BOSH) and WebSockets (both supported by any modern server) to give an amazingly powerful and broad JSON API.
On the other hand, XMPP-FTW uses a server-side thin proxy to translate the XML-based standard TCP session (supported by every server) into a JSON API, presented over traditional browser tech like Primus, allowing the client session to switch between transports on the fly.
And not only that, but they're the same JSON translator code, now, so switching between them is as comfortable as it gets.
You can even make WebRTC calls using XMPP's Jingle signalling technology from one stack to another, or indeed to the original Strophe.js library too - hardly surprising, since Jingle hugely influenced the capabilities of WebRTC during its design. In fact, desktop XMPP clients are actually playing catch-up on this front, because WebRTC pushed the boundaries so quickly - on that front, at least, one could argue that XMPP is more at home on the web than it is anywhere else.
41

edits

Navigation menu