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 a MakeService (a Service that returns a Service) pattern. After "making" a service (the http1 or http2 (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 its Drop 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 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
Eitherpool to combine them.When looking how the legacy
Clientuses the pool, they easily fit into aMakeService(aServicethat returns aService) pattern. After "making" a service (thehttp1orhttp2(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 itsDropimplementation, 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.