cloudflare
Move h3 implementation to separate crate
Splitting h3 out of quiche into its own crate (e.g. quiche-h3 or h3) for a clarify separation between QUIC and HTTP/3 layers.
Currently the h3 implementation uses non-public quiche function e.g. quiche::Connection::dgram_enabled or fields such as quiche::Connection::grease.
This would help to expose a better API for protocols that want to build directly on QUIC.
Thanks for doing the work on the associated PR but it seems like a rather huge breaking change and I'm not sure that balances well against the concrete value it brings.
The quiche API already supports non-HTTP/3 use cases. If there are functions that we can make public to help other application mappings, such as whether datagrams are enabled, then that would seem like a much lower impact change to make as seperate PRs
Totally understand the concern - this is indeed a larger breaking change.
The motivation behind the split is primarily around maintainability and easing onboarding for people (students) using the codebase. Cleanly separating the QUIC transport layer from the HTTP/3 application mapping could make the codebase easier to work with.
That said, I’d still be interested in exploring the split further down the line if there’s interest.
Cleanly separating the QUIC transport layer from the HTTP/3 application mapping could make the codebase easier to work with.
The code is already structured that way, the QUIC module is independent of any application mapping, the HTTP/3 module builds on top of it by using the public API (except in places where we've overlooked adding a pub that can be done easily). A crate separation adds a different boundary but from a code perspective I don't think it improves much.
We don't have plans to make the h3 module generic over other transport implementations. Strong cohesion between the layers ensures we can add features or changes and plumb them through without code or performance overheads.
Coming back to this, its not something we want to do for the reasons explained previously. It would cause a lot of churn in real projects and deployments for little practical benefit. Therefore, closing it as not planned.