Hi Justin, This is not uninteresting at all. Javascript programmers are pressuring us : "we want JSON not XML" (for presumed performance reason, while using dom everywhere in their web pages)
Good thing to put the issue on the table. > this could mean native clients needing to speak JSON to interact with certain > endpoints That is where I would not not. I would rather do a gateway on the edge for JSON clients in order to preserve XMPP (from language specific excesses). Valentin ________________________________ De : Justin Karneges <[email protected]> À : [email protected] Envoyé le : Lundi 28 janvier 2013 12h29 Objet : [Standards] a modern HTTP binding With the summit coming up, I figured I'd write out what's been on my mind since the previous summit regarding BOSH and XMPP's relevance in the web world. These days, people building web apps expect to have sessions that persist across tabs, and they expect to be able to use JSON. That's just the way web development works. Browsers are becoming a lot smarter lately and maintain more client state, but we're still not at the point where a multi-tabbed website can have entirely local state on par with native clients. BOSH is an awesome XMPP tunnel, but it's a poor "binding" of HTTP. It treats HTTP like it's this awkward thing we have to navigate around rather than recognizing that HTTP is not entirely terrible and REST generally makes good sense. IMO, the only interesting use of XMPP at the browser level is what was proposed by Dave Cridland at the recent Realtime Conference. The browser should be able to natively establish an XMPP session that is then shared across tabs. What I propose here is a new HTTP-based binding that simulates Dave's goal with the help of a gateway (session stored on the server). A JavaScript API should exist that can send/recv stanzas over some sharable XMPP session. If the browser has native support, then the user himself would initiate the connection using UI external to the HTML. If not, then we'll need some extra API to initiate sessions that can be triggered from within the HTML. It should also look good under the hood. One HTTP POST request to create a session. Authentication provided using HTTP auth. Server responds with a Cookie header that is used for all subsequent activity. HTTP POST to send a stanza. HTTP GET (long-polling) to receive stanzas. No long-poll flip flopping like BOSH. To assist with sharing state across tabs, stanzas would be readable by all tabs. No extra effort is needed to achieve this as long as all the long-polls are requesting for data against the same checkpoints. The gateway would persist received stanzas for a few minutes, for any number of browser tabs to query against. To communicate across tabs, send data to yourself. Content-neutrality. At the summit there was some talk about JSON<->XML mappings. I'd argue that we don't necessarily need a mapping. We just need a way to send JSON at all, untainted. Bear with me here. One of the great features of HTTP is the ability to specify the content type. HTTP survived the web world's transition from XML to JSON. The fact that XMPP baked-in its data format was arguably very cool at the time of its origin, but it's not future proof. Imagine this: <message from="alice" to="bob"> <content "urn:xmpp:altcontent" type="application/json"> lots of curlies </content> </message> The idea here is to define a stanza in more abstract, as a set of simple properties (from, to, type, id) and arbitrary content a la HTTP. If an altcontent payload is not present, then the content is XML. If it is present, then the content is anything else. There we go, universal transport without changing XMPP's version number. I'm not kidding: <message from="alice" to="bob"> <content "urn:xmpp:altcontent" type="image/png" content-encoding="base64"> lots of printable chars </content> </message> What this means is that a developer can write a webapp that speaks JSON between two JIDs, using a very straightforward REST API. The JSON for a message stanza from the perspective of the developer could look like: { "type": "message", "from": "alice", "to": "bob", "content": { ... } } Of course, if you try to communicate with an endpoint that doesn't understand the JSON that you're sending, then it won't work. But that's the way of the web. Different entities work with different types of content. We deal with it. That all said, I do think we should define mappings for IM and pubsub constructs so that they are ready to use from the web. Everything else stays XML. If a web client wants to speak Jingle, for example, then it builds XML like a man. And yes, this could mean native clients needing to speak JSON to interact with certain endpoints. This is how we evolve. </three-am-brain-dump> Justin
