The recent release of hyper 1.0 and onwards has changed a large portion of the API that Bollard was exposed to. I'll try to keep this ticket up-to-date with my findings.
This piece of work should require these independent parts, where I'm happy to have some help if there's motivation.
Upgrade hyperlocal, which is possibly no longer maintained. It looks like a fairly straightforward upgrade if using the hyper-util legacy client, at least on the client-side, but that might be undesirable long term. (any help here updating / adopting much appreciated).
There is an existing PR that works for Bollard's needs.
Upgrade hyper-rustls - there is a PR being worked on already, so I'm hopeful this work should be useable soon, and it looks useful as a reference.
This aforementioned PR is merged and release 0.26 contains the needed hyper upgrade.
Hyper 1.x uses significantly different semantics of Request/Response body types, streaming and upgraded connections, which I've been working on in Bollard in a local branch.
Hyper 1.x has extracted the async read/write traits in order to distance itself from the Tokio type system and let other execution runtimes such as Fuchsia / Curl be used.. Unfortunately, in Bollard we still uses these traits to frame payloads, and the buildkit feature uses it for grpc communication, so we'll need to provide tokio wrappers.
There is a "named-pipe" module in Bollard, which I haven't looked at yet, that would need to be upgraded to use Hyper's new API - I'm wondering if this should be replaced by something else or we can break it out into another crate. Any help here much appreciated.
In parallel the rustls 0.22 upgrade is possibly also needed, which does look like a smaller change in the API, but nevertheless could be tackled separately.
yup-hyper-mock also needs to be upgraded to use hyper 1.x
The recent release of hyper 1.0 and onwards has changed a large portion of the API that Bollard was exposed to. I'll try to keep this ticket up-to-date with my findings.
This piece of work should require these independent parts, where I'm happy to have some help if there's motivation.
buildkitfeature uses it for grpc communication, so we'll need to provide tokio wrappers.