async framework agnosticism?

[rdaum]

This a great project. I have a question though about the goal in regards to async support. I see that as things are right now there's a dependency on tokio -- which I think rules out use w/ other async runtimes (like smol or glommio, etc.)

It seems most uses are just on tokio::sync, for which there are potential platform agnostic alternatives. (async_channel etc.).

However there is one use of tokio::spawn @ https://github.com/BiagioFesta/wtransport/blob/8ca6e2003506467b2d6f97f5f6cda6729b8f9112/wtransport/src/driver/mod.rs#L55 and I don't think there's a way to do the equivalent without a runtime dependency. So I guess there'd need to be some refactoring to make that feasible (perhaps a trait and separate pluggable TokioDriver behind a feature or separate crate?)

Curious what the thoughts of the project maintainers are here. Thanks!

[BiagioFesta]

Thank you for the feedback :)

Tokio has been selected as dependency mainly because it is what underlying QUIC implementation (quinn) dependency does. QUIC I/O runs within the tokio runtime (not only the engine of wtransport).

Lately, quinn library generalized the async runtime and implemented it for tokio and async-std (see here). Therefore, it would be possible to follow the same approach and provide support for async-std as well (behind features flags). That's something I had on my roadmap, but I don't think it is really urgent for now (as tokio is the most common async runtime nowadays).

[rdaum]

Thanks that makes sense.

Interestingly, this just came across r/rust:

https://tquic.net/blog/tquic-open-source/

Alternative QUIC impl for Rust that doesn't mandate any particular runtime, or async at all really:

"The TQUIC core employs an abstraction design for network I/O and event loop, and it doesn't rely on sockets, but rather user-provided callbacks. Furthermore, the TQUIC core doesn't impose specific event loop requirements; instead, it offers functions to assist users in scheduling events. This flexibility makes TQUIC easy to customize and integrate into various systems.

[BiagioFesta]

It seems quite similar to https://github.com/cloudflare/quiche

The idea of wtransport is to provide an ergonomic async interface for webtransport programming. The idea is to hide the complexity of QUIC/HTTP3 and all UDP I/O inside an inner driver.

However, wtransport-proto (crate of this very same workspace) provides the protocol logic without assuming any I/O (so, in theory, one could build on top of that with its own I/O)