As a server developer I'm in a good position to implement this, and every so often (a couple of times a year), someone will ask for it.
There are two approaches that could be taken. The first is to attempt to map XML losslessly to JSON. This does not end well. JSON's simplicity as a data structure is lost, because it doesn't support namespacing, on which XMPP relies heavily. For a fun take on this, but grounded in reality, see XEP-0295: http://xmpp.org/extensions/xep-0295.html
The second approach is to drop namespaces, which means dropping the 'extensible' part, and defining some mappings of common stanzas (XMPP 'packets') to and from JSON. This is what xmpp-ftw aims exactly to do (on the client side): https://xmpp-ftw.jit.su/
I personally think the second way is saner, if you accept that you're closing the door on one of the main features of XMPP provides - interoperability between a diverse set of clients.
Now whether the translation ought to happen on the client or the server side is up for debate, and depends on why you feel you want JSON in the first place. If it's simply to ease your life as a developer, the client is better - just use a high-level library like xmpp-ftw and forget about it. If it's because you have some low-end platform where a streaming/SAX XML parser isn't available, you really do want JSON (or more likely, something even lighter) as the wire protocol.
"I personally think the second way is saner, if you accept that you're closing the door on one of the main features of XMPP provides - interoperability between a diverse set of clients."
Might I just add that we are in the context of discussing an article in which that feature was just used. A new namespace was defined by fanout.io and deployed, and it's all perfectly standard and working.
Those who think that XMPP can just drop in JSON don't understand how extensively XMPP uses XML, and probably don't fully understand everything the XML stack adds.
The history of XML in a nutshell is that it was designed for documents, but got used by a lot of people for data. For data, XML was massive overkill. The masses, as usual, overreacted and declared that XML was overcomplicated and bloated and useless. This is not true. It's actually a very nice set of standard functionality to use... when you need it. If you don't need extension namespaces or tag attributes in addition to contents (two dimensions of attributes, basically) or markup in your text, etc etc, don't use XML. On the other hand, if you do need those things, equally strongly, don't use JSON! It turns out XMPP uses all of the above, plus some more. Those who propose switching it to JSON, IMHO, merely demonstrate that they don't understand the tradeoffs in question, and probably have an irrationally-strong aversion to XML.
I, ironically, say this in the context of someone who in my job have almost always called for XML to be replaced by JSON. This is because in those cases, it was the right answer. I suppose, sooner or later, the opposite will happen.
100% agreed, and I'm in a similar position. I often mention to people that XMPP is one of the few places where I think XML is actually the right tool for the job, and is actually being used properly.
This is rather in contrast to those infamous "enterprise" frameworks, APIs and protocols that standards committees shoe-horned XML into as a way to put another tick in another box, that we have all grown to hate. Long may the rebellion continue!
This has been discussed many times, but so far, no clear advantage of changing the wire-protocol, to be based on JSON instead of XML, has been shown. Especially if you want to retain distributed extensibility you will mostly end up with curly brackets instead of angle brackets. Sure, dealing with the DOM in the browser is not awesome, but in general this could be dealt with by having better library APIs instead of changing the wire-protocol.
That said, a minimal protocol addition like this, which just provides an element to wrap serialized JSON for payloads, definitely help with minimizing that DOM pain. I will propose standardizing this as a (very short) XEP (XMPP Extension Protocol) with the XMPP Standards Foundation.
> That said, a minimal protocol addition like this, which just provides an element to wrap serialized JSON for payloads, definitely help with minimizing that DOM pain. I will propose standardizing this as a (very short) XEP (XMPP Extension Protocol) with the XMPP Standards Foundation.
Other than jokes, I think the closest we have to something real is XMPP-FTW, which operates as a gateway and JSON-ifies everything between itself and the XMPP server.
Personally, I'd like to see XMPP go format-agnostic, just like HTTP. What's funny is that there was already a competing protocol that did exactly this called BEEP, created around the same time as XMPP. Developers ultimately preferred XMPP, and I'd attribute this partly to the fact that the payload format (XML) was baked into the protocol. Back then, people loved their XML about the same as people love their JSON today.
There are two approaches that could be taken. The first is to attempt to map XML losslessly to JSON. This does not end well. JSON's simplicity as a data structure is lost, because it doesn't support namespacing, on which XMPP relies heavily. For a fun take on this, but grounded in reality, see XEP-0295: http://xmpp.org/extensions/xep-0295.html
The second approach is to drop namespaces, which means dropping the 'extensible' part, and defining some mappings of common stanzas (XMPP 'packets') to and from JSON. This is what xmpp-ftw aims exactly to do (on the client side): https://xmpp-ftw.jit.su/
I personally think the second way is saner, if you accept that you're closing the door on one of the main features of XMPP provides - interoperability between a diverse set of clients.
Now whether the translation ought to happen on the client or the server side is up for debate, and depends on why you feel you want JSON in the first place. If it's simply to ease your life as a developer, the client is better - just use a high-level library like xmpp-ftw and forget about it. If it's because you have some low-end platform where a streaming/SAX XML parser isn't available, you really do want JSON (or more likely, something even lighter) as the wire protocol.