Websocket transport

[abh]

Is the websocket transport missing or am I missing something obvious about how to hook in one of the other websocket packages to just use the conn transport?

[dmcgowan]

The network transport is actively being worked on right now. Since spdy will be the primary network transport, the websocket support will be spdy over websockets. See the ws package in https://github.com/docker/spdystream for how to use it. Pure websocket support is certainly possible in order to operate with browser-side javascript, but that would need to be considered a completely separate network transport than the spdy implementation.

[mcollina]

I think running SPDY over Websocket (over HTTP/SPDY/HTTP2) might require too many layers to work well in the browser (primary goal of the WS transport, IMHO). So, I think we need a completely separate network transport for it. Just a flow of msgpack packets that identifies the channel/bytestream to route the data. There will be overhead and it will have a naive scheduler, so performance might be bad, but maybe good enough for a browser-based app.

The other option is a brand-new SPDY implementation in JS that can run on top of WebSocket. Of course it is not undoable, but is it worth it?

What do you think? Also @AdrianRossouw and #11.

[dmcgowan]

I like the other option, reason being that spdy is the protocol defining the multiplexing in libchan, any other transport implementation on websocket would just end up redefining a different multiplexing protocol. I see libchan as an implementation on spdy, and spdy as a flexible protocol which can be implemented on any network transport. Any other libchan transport implementation should only be done because it uses a legitimately better multiplexing protocol than spdy (e.g. QUIC).

[dmcgowan]

Closing this issue as already possible, added an issue to create an example to demonstrate.