You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While http 2.0 isn't finalized yet, it is in draft phase, and only a few months from being submitted (Nov 2014). There are a few things which I think would benefit greatly by taking advantage of the multiplexing capability.
The most obvious and beneficial use case I see is attaching to containers. Right now, if you want to connect to STDIN/STDOUT/STDERR of a running container, the process/protocol is rather cumbersome. Utilizing a transport protocol which supports stream multiplexing would make this process a lot simpler. Custom clients wishing to attach using the remote API would then be able to use standard http 2.0 libraries, instead of having to hand-code the protocol.
This would also make it a lot more flexible for adding additional streams. I'll use one of my own issues here as an example, #6396. This issue is to allow forwarding the ssh key agent to the daemon so that it can be used by containers. Doing so requires establishing another stream to the daemon. For output, this isn't an issue as the attach call sends each chunk of data prefixed with the stream number. However for input this isn't possible as the daemon assumes all input is STDIN.
Utilizing http 2.0 would make this sort of extension very easy.
There are other less significant, but still beneficial, uses such as being able to use the same TCP connection for uploading & downloading images in parallel.
While http 2.0 isn't finalized yet, it is in draft phase, and only a few months from being submitted (Nov 2014). There are a few things which I think would benefit greatly by taking advantage of the multiplexing capability.
The most obvious and beneficial use case I see is attaching to containers. Right now, if you want to connect to STDIN/STDOUT/STDERR of a running container, the process/protocol is rather cumbersome. Utilizing a transport protocol which supports stream multiplexing would make this process a lot simpler. Custom clients wishing to attach using the remote API would then be able to use standard http 2.0 libraries, instead of having to hand-code the protocol.
This would also make it a lot more flexible for adding additional streams. I'll use one of my own issues here as an example, #6396. This issue is to allow forwarding the ssh key agent to the daemon so that it can be used by containers. Doing so requires establishing another stream to the daemon. For output, this isn't an issue as the attach call sends each chunk of data prefixed with the stream number. However for input this isn't possible as the daemon assumes all input is STDIN.
Utilizing http 2.0 would make this sort of extension very easy.
There are other less significant, but still beneficial, uses such as being able to use the same TCP connection for uploading & downloading images in parallel.
There's a list of libraries implementing HTTP 2.0 at https://github.com/http2/http2-spec/wiki/Implementations which lists one for GO at https://github.com/Jxck/http2.
The text was updated successfully, but these errors were encountered: