Inets http2 support
Tue Nov 26 11:09:57 CET 2019
On 26/11/2019 10:39, Adam Lindberg wrote:
> @Lukas, @Loïc: Working on QUIC separately would still be beneficial though, right? Or is there something in HTTP/3 that requires tighter integration with QUIC that a separate implementation would not provide?
I am definitely talking about separate implementations, QUIC could be in
OTP or third party and HTTP/3 would just sit in Cowboy/Cowlib.
What HTTP/3 would provide to QUIC development is a use case that uses
most of the features from QUIC and would allow optimizing QUIC. I'm
thinking for example of the synchronization part of QPACK, of the
different types of streams QUIC is using, and so on.
I don't think HTTP/3 would have a significant impact on the features of
the QUIC library though. There might be an exception to that, and that's
currently an unknown due to the lack of consensus, and that is the
priority mechanism. It's arguably more into optimization territory as
So yes it's fine to work on them separately. I just think about the full
picture since I'm mostly interested in HTTP myself. If I started working
on this today I would focus on getting the HTTP/3 part before QUIC
because I'm more interested, not because of any coupling between the two.
More information about the erlang-questions