[nmjenkins]

(Author of the spec here)

The protocol could just as easily go over a WebSocket as HTTP (you'd have to change authentication mechanism, but that would be trivial). The only reason we don't do that at the moment is: 1. Browser support (we support back to IE8, unfortunately) 2. Lack of GZIP compression (particularly of responses from the server); this was being worked on last time I looked, but I haven't checked recently to see if it's been implemented yet. This is crucial for saving bandwidth.

That would get rid of your HTTP overhead; I will put some mention of that in the spec (I think HTTP support should be required, and WebSocket support optional).

As for JSON vs. binary: * There are libraries to use JSON everywhere – binary protocols would require everyone to implement another parser, adding extra difficulty for adoption and a surefire source of bugs. * JSON is readable over the wire, binary is not. Trust me, in the real world, this is a huge advantage for debugging all sorts of things. * JSON can be used trivially in a web app. Apparently this World Wide Web thing might catch on. * The parsing overhead of JSON is not too large; yes it's longer than a binary protocol, but it hasn't been a bottleneck for us, even on mobile.