Re: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system)

[Christian Huitema <[e-mail]>]

On 8/6/2020 5:58 PM, David Schinazi wrote:
> In theory, it could mean that one could write an application
> in such a way that it could swap QUIC implementations.
> I don't see that happening in practice. The application
> developer would have to periodically test against these
> implementations for them to work reliably, so the idea
> of a drop-in replacement sounds unreal to me.

Yes. We had an example of that when testers wanted to plug their tools
to different QUIC stacks. Not impossible, but there was a lot of glue
required.

>
> Additionally, in 2020, networking APIs are asynchronous.
> That means that a QUIC API would need to be tied to
> a specific asynchronous IO model, and those are tied
> to programming language and library choices. So any
> API would only work for applications that pick the same
> language and standard libraries.


People today are experimenting with a variety of application--stack
interactions. I think that's a good thing at this point. Take the
example of out-of-order delivery: really cool potential, but we have
very little experience. It might require tight integration with the
application, dealing with the intricacies of video codecs. I think that
in the next year or two we will gain some experience and maybe see a
small number of API models emerge. But attempting standardization before
that seems very premature.

-- Christian Huitema