Should client::conn::http2::SendRequest be Clone?

[vi]

Should hyper::client::conn::http2::SendRequest be Clone, just like h2::client::SendRequest?

[seanmonstar]

Hm, probably yes. It should also likely internally use the UnboundedSender (if it isn't already) which allows it to be cloned and so on.

[LucioFranco]

This should probably extend to h1 as well?

[seanmonstar]

h1 can't send multiple requests concurrently.

[LucioFranco]

Right but there is a buffer in-front of the sending task so imo we should model the api like that even if it doesn't send them concurrently?

[seanmonstar]

I don't believe the h1 side has much of a buffer... I think only a slot of 1, where the SendRequest puts the next request, and then the dispatch task can poll and take it to serialize to IO. Any more of a buffer for h1 should like be done with tower::buffer, I think.

[LucioFranco]

@seanmonstar so for a thick client, the idea will be that it will add that clone portion on top of the h1 portion to make the h1 and h2 api's match? That was my concern was that these two very (same named) similar types have different implementations.

[seanmonstar]

If a client wanted to serialize requests over the single connection, they could. What hyper::Client used to do was reuse the same HTTP/2 connection by cloning it, and use new HTTP/1 connections by calling connect().

I don't think at the conn::http1 layer we should be making work exactly the same as conn::http2.