hyper-util: deconstruct legacy Pool into composable Services #3849
Labels
A-client
Area: client.
B-rfc
Blocked: More comments would be useful in determine next steps.
C-feature
Category: feature. This is adding a new feature.
E-medium
Effort: medium. Some knowledge of how hyper internal works would be useful.
K-hyper-util
Crate: hyper-util
The internal connection pool in the legacy client does many things, and it'd be better if it were broken up into several pieces and those made public, so people can more easily construct their own pools. Such as a racing cache pool, singleton pool for HTTP/2, an
Either
pool to combine them.When looking how the legacy
Client
uses the pool, they easily fit into aMakeService
(aService
that returns aService
) pattern. After "making" a service (thehttp1
orhttp2
(SendRequest, Connection)
bit), a request is then sent, and afterwards the service is dropped. If pooling were disabled, that would just make a new connection each time. If a pool is used, likely that "made" service would return some internal pieces in itsDrop
implementation, so that making a new service later would reuse the existing connection.This is likely a more complicated task, and a design document would be a good next step. I'll also add here some subtasks for individual pool types worth adding.
The text was updated successfully, but these errors were encountered: