Fundamentally, we wanted an interface to QUIC that we could integrate with our existing server systems. Our servers, naturally, have their own methods of handling a wide range of things like: socket addressing; events state; memory management; TLS handshake processing; request and response processing; and we needed our QUIC implementation to be as independent of these notions as possible. Looking at a library like quinn and some other QUIC implementations, we see that these APIs are tied to many of these external notions, and specific implementations of these notions for that matter, one example being the core protocol objects in quinn that directly link to specific socket and address and even event loop reactor objects - and these objects strictly in Rust to boot.
It was obvious from our experience with our first QUIC proof of concept, and from our evaluation of options for our continued QUIC offerings, that existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.
It was obvious from our experience with our first QUIC proof of concept, and from our evaluation of options for our continued QUIC offerings, that existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.