send_data for arbitrary buffer type

[yu-re-ka]

The buffer type should not be fixed for a connection or stream. It should be a generic parameter of the send_data function, so that each send_data call on the same stream can have a different buffer type.
This is because when h3 is eventually integrated with hyper, hyper will need to send whatever buffer type the response HttpBody has.
The main issue here is tracking the write progress of an asynchronous write operation. With the current API, it is guaranteed that multiple writes can not be running simultaneously, which would result in them being garbled together.

quinn itself uses the following function signature:

    pub fn write<'a>(&'a mut self, buf: &'a [u8]) -> Write<'a> {

The returned Write struct is a future that contains a mutable borrow of the stream.
I don't know if it would be possible to do something similar with the h3::quic traits.

[seanmonstar]

What's wrong with the buffer type being generic on the connection? The generic propagation works similar to h2, the Body type must return the same type of buffer for the lifetime of the connection. But that doesn't mean the buffer type can't be dynamic. It can be an enum of different strategies, or be a trait object even.

[yu-re-ka]

I see how that could work as well, since one server (producing connections with one buffer type) will always serve the same known service, with its known Response buffer type.
However then there is a different problem: h3::server::Connection::new() is fixed to connections using the Bytes buffer.

This means effectively I can't use h3 right now with any Response buffer other than Bytes.
However I think the proposal of moving the generic parameter to the send_data function is better since it prevents carrying around the buffer type everywhere.

[Ruben2424]

I think the h3::server::Connection::new() function is already fixed and now generic over the Buffer.
But I will leave the issue open for further discussion about moving the generic Parameter to the send_data function.