Ask HN: Do We Need Both Websockets and The Wave Protocol?
I do not quite grasp the difference between the two as they both appear to use push technology to communicate data real time. Are we splitting what could be one? It reminds me of a common problem from the WEB2.0-era, S-EXP. vs. XML vs. JSON. Basically breaking the web unnecessary much.
3 comments
They don't solve the same problem. The Wave protocol is a higher-level document-based protocol and WebSockets are a transport layer. In fact they can be used together:
http://www.waveprotocol.org/protocol/design-proposals/client...
To explain at greater length, WebSockets are much simpler. If you wanted to do something simple, like let your website's users chat with each other, you could whip something up with WebSockets. If you wanted to do something complicated, like a real-time cooperative game, you could use WebSockets as the basic structure that you would built a more complicated messaging system on top of. A WebSocket is a two-ended pipe, client to server, and if you want a more complicated network structure you have to create that yourself.
The Wave protocol is much more complicated and aimed at a more specific case. It is built on the idea of shared documents which is at a higher level than sockets. It contains specifications for things like cursors and deleting segments of text in documents. If you were building a system that did not have something akin to shared documents, it would probably not make sense to use the Wave protocol. But if you were building a system based on shared documents, like an EtherPad clone, then the Wave protocol might be perfect and save you a lot of work.
They are not really direct competitors like JSON vs XML. It is more like comparing HTTP to XML. You could operate the Wave protocol over WebSockets, just like you could send XML over HTTP.
http://www.waveprotocol.org/protocol/design-proposals/client...
To explain at greater length, WebSockets are much simpler. If you wanted to do something simple, like let your website's users chat with each other, you could whip something up with WebSockets. If you wanted to do something complicated, like a real-time cooperative game, you could use WebSockets as the basic structure that you would built a more complicated messaging system on top of. A WebSocket is a two-ended pipe, client to server, and if you want a more complicated network structure you have to create that yourself.
The Wave protocol is much more complicated and aimed at a more specific case. It is built on the idea of shared documents which is at a higher level than sockets. It contains specifications for things like cursors and deleting segments of text in documents. If you were building a system that did not have something akin to shared documents, it would probably not make sense to use the Wave protocol. But if you were building a system based on shared documents, like an EtherPad clone, then the Wave protocol might be perfect and save you a lot of work.
They are not really direct competitors like JSON vs XML. It is more like comparing HTTP to XML. You could operate the Wave protocol over WebSockets, just like you could send XML over HTTP.
One's (very nearly) a socket, the basic communication primitive used by almost everything to implement higher level protocols.
The other is a high level protocol that sits on top of a socket and does all kinds of various presumably-wonderful things, but is not itself a socket. Trying to replace sockets with Wave would be a major step backwards; the reason we need websockets in the first place is that the high-level HTTP protocol embeds assumptions that are not always correct for a given application and therefore gets in the way; Wave would be even worse about that.
Google Wave is one of the many protocols that can be built on a socket. Wave and HTTP are peers, sockets are the foundation they both sit on, WebSockets are as close to sockets as the web will let us get.
(It should be pointed out that WebSockets still are not the ultimate in flexibility; the TCP that WebSockets sit on itself makes assumptions about applications that are not appropriate to all applications, which is why not every packet on the internet is a TCP packet. I've glossed over some other details too, which in my judgment would only confuse at this point.)
The other is a high level protocol that sits on top of a socket and does all kinds of various presumably-wonderful things, but is not itself a socket. Trying to replace sockets with Wave would be a major step backwards; the reason we need websockets in the first place is that the high-level HTTP protocol embeds assumptions that are not always correct for a given application and therefore gets in the way; Wave would be even worse about that.
Google Wave is one of the many protocols that can be built on a socket. Wave and HTTP are peers, sockets are the foundation they both sit on, WebSockets are as close to sockets as the web will let us get.
(It should be pointed out that WebSockets still are not the ultimate in flexibility; the TCP that WebSockets sit on itself makes assumptions about applications that are not appropriate to all applications, which is why not every packet on the internet is a TCP packet. I've glossed over some other details too, which in my judgment would only confuse at this point.)
The Wave Federation Protocol applies the old-school newsgroups philosophy of a local server handling storage and federation of communications (perhaps about a document, as in Google Wave, but more generally about arbitrary things) so that there are far fewer redundant transmissions of data. Bandwidth is much cheaper now than it was in the early days of the internet, but this does have potentially interesting applications.