Hi all,<p>As the author of xmpp-ftw I feel I should throw some comments into this discussion.<p>Firstly, xmpp-ftw is not about starting an XML/JSON holy war, its about lowering the barrier to entry as far as possible. So see it as more of a gateway drug :) *<p>At present the tiny amount of effort it takes to build a proprietary (legacy) chat system with other technologies means that XMPP is somewhat being left behind (on the web) despite offering a huge number of benefits. Xmpp-ftw tries to make it as easy as possible by providing developers a format they are comfortable with and the ability to send/receive data with the minimum of fuss.<p>This project actually came out of discussions at XSF summits I've been attending. No-one (myself included) believes that XML should be replaced with JSON in XMPP, that would be a foolish notion. Generic JSON <-> XML is awful and doesn't quite work. The idea with this project was to used named events to fill in some of the missing information for building stanzas, and telling the user what is happening.<p>The view of JSON with XMPP has changed over the last couple of summits has changed, going from being referred to as the J word' through to open discussions about what can be done (the XSF seems like a very progressive group). No more jokes about XEP-0295 :)<p>If you want to see a better client library trying to do something similar check out Lance Stout's stanza.io <a href="https://github.com/legastero/stanza.io" rel="nofollow">https://github.com/legastero/stanza.io</a> which came out of the same meeting.<p>So in summary: Xmpp-ftw is attempting to drop the barrier to entry for XMPP as far as possible and make it quick and convenient for developers to implement. Its not about replacing the angle brackets :)<p>Cheers, Lloyd<p>FYI, yes I've used socket.io, but you can stick anything that implements an event emitter and has callbacks and have it work. Currently I'm looking at wrapping sockJS.<p>* Drugs are bad m'kay!
I don’t understand the point of taking an existing protocol – with fairly well defined syntax/semantics, which has presumably been tested at various parts of the stack, likely has existing conformance tests, &c. – and wrapping it in a new ad-hoc protocol which has (some subset of roughly) the same semantics, just for a syntax change? Big addition of new complexity for little tangible benefit.<p>Why not just use one of the existing Javascript implementations of an XMPP client, or if they’re unsuitable for whatever reason, make a new one?
There are a couple of key points here which a lot of you are missing which are:<p>* The JSON -> XML conversion is done on the server rather than in the client. Browsers are surprisingly bad at xml (one of the reasons buddycloud chose to move the xmpp layer out of the browser), and xml dom manipulation can make for overly complex code (we should also bear in mind one of the philosophies of xmpp which was simple clients, complex servers), and this leads me to my second point:<p>* It's really simple. This opens it up as a no-brainer solution for web devs who would otherwise just throw up a proprietary silo system based purely on socket.io or similar. Sure, if you really want all the complexities and nuances of xmpp then use an xml based library, but if you just want to send simple messages between users then this is really simple, and hey - what would have been a silo system is suddenly federatable at zero cost.<p>The point here is that this library is not aimed at hardcore xmpp devs, but devs who would be put off by anything other than json. Make this library as easy to use as socket.io on its own and suddenly you've got more systems running on xmpp which wouldn't otherwise have been (which is great for everyone)!