HTTP/2 transport about libchan

[dmcgowan]

@mcollina brought this up to me earlier. I am for defining the HTTP/2 based protocol as soon as possible. As part of this transition, I would like to first take the step of separating out the existing spdystream stream implementation to a more abstract stream interface. This interface would then have implementations for spdystream (should work exactly as today) as well as HTTP/2. It would also allow us to explore using libchan on top of SSH or customized multiplexed implementations for file sockets and websockets.

[dmcgowan]

Switched to help wanted and into 0.2.1 milestones. I will not be able to own this anytime soon so it might need to be pushed out. The 0.2.0 version will introduce the stream interface which http/2 will need to implement. Implementing this feature should not involve deep changes to libchan, only adding a stream provider implementation.

[pnasrat]

Any interest in grpc or just http/2?

[pnasrat]

Active go development for http2 https://github.com/bradfitz/http2

[dmcgowan]

The next version of libchan will have the underlying transport abstracted away using this interface https://github.com/dmcgowan/streams. The codec will also be behind an interface to support different codecs in the future. This is mostly to keep the role of libchan smaller, which is to expose a method for sending and receiving messages which can contain channels and byte streams (as any io.ReadWriteCloser). This basic functionality unlocks the potential for doing very powerful RPC on top of it, but the scope of libchan is not to define an RPC layer. Grpc appears to be a full RPC solution, I don't think it and libchan have any need for each other. It does look like a cool project though and would love a further explanation if you disagree.