hyper-util: What is the roadmap for the legacy client?

[NielDuysters]

Hi

I am volunteering for the Tor Project which is making a new implementation in Rust called Arti.

Previously we had a crate providing an extra layer on hyper allowing it to be easily implemented into Arti. But since hyper 1.x this crate was deprecated because making a request through Arti using hyper became easier as this example demonstrates.

But we noticed that the lack of a custom connector is now missed by our users. In MR!2941 we are planning on resurrecting the arti-hyper crate.

But AFAIK this is only a logic choice when the user is able to use the legacy client for hyper_util to use the request method from that client to make requests.

I am wondering what the planned roadmap for the legacy client in hyper_util actually is. In client/legacy/client.rs I e.g see the following comment:

//! The legacy HTTP Client from 0.14.x
//!
//! This `Client` will eventually be deconstructed into more composable parts.
//! For now, to enable people to use hyper 1.0 quicker, this `Client` exists
//! in much the same way it did in hyper 0.14.

What exactly is meant by this? Are you planning on supporting this legacy client in the far future too?

[silamon]

I guess a part of your answer is to be found in #3948 .

[seanmonstar]

As long as the replacement has not been completed, we'll fix bugs in the legacy one. But it is not accepting any new features. Those should be layers, such as talked about in https://seanmonstar.com/blog/hyper-util-composable-pools/.

Once enough layers exist in hyper-util to re-implement the legacy client, legacy::Client will be removed.

[WhyNotHugo]

I've submitted a UnixConnector for connecting via a Unix domain socket (e.g.: to a locally running HTTP server, tunnel, etc).

I'd appreciate guidance on what this should look like as a layer; I can port this to a non-legacy approach too and also use it as a reference for other bits I'm currently using.