On Wed, 28 Jun 2017, Lucas Pardue via curl-library wrote:
As you're probably fully aware, QUIC doesn't just carry HTTP/2 frames - it subsumes things and generally messes around. (lib)curl shouldn't expect to just be able to reuse libnghttp2 (in its current form). Therefore the selection of QUIC library should probably be cognisant of what will provide the HTTP/QUIC implementation, and how well those components would integrate.
Good and valid points. I'm actually assuming that HTTP-QUIC (hq) frames will be different enough from h2 so that the quic libraries will do that tranformation for us much how the h2 libraries do. The frames already differ notably and we're not done yet. So yeah, the library (or libraries) we pick should either do that for us or we'll have more work to do ourselves... So we pick a QUIC solution that is stand-alone and independent of the h2 solution.
Substitution of components (i.e. do you want to support plugging of different HTTP/QUIC implementations, or pick one) should probably be discussed or at least written down.
I personally think we should pick one library and stick to that. To focus our efforts on one problem instead of distributing it over many. It is also less complex and will help future users.
This said, I won't argue a whole lot against multi-lib support if someone is actually interested and willing to put in the work to support a second down the line. It would be crazy to start off supporting more than one I think. I'm convinced QUIC in itself is complicated enough, no need to add more challenges!
2) Alt-Svc
While Alt-Svc is needed for QUIC, QUIC isn't needed for Alt-Svc. What I mean is do you see a piece of work on Alt-Svc covering all aspects of its capabilities, or to constrain it to QUIC? ALTSVC frame handling springs to mind.
That's just a result of my pragmatism. We more or less need Alt-Svc for kickstarting QUIC the way browsers do, so that's the minimum level of Alt-Svc compliance for us as I see it. Then Alt-Svc can be used for much more than just QUIC so there are more reasons to add support for handling this header and the ALTSVC HTTP/2 frame, but I don't mention them here since they're then not about QUIC.
How closely coupled with libcurl do you see your Alt-Svc cache being (could it be a completely separate component?). I think an in-built Alt-Svc cache for the curl tool makes a lot of sense, however for libcurl I'm not so sure. Without putting too much thought into it,
That's a good question that I haven't thought about much. My thinking was to start with just an in-memory cache that would be used as long as your libcurl handle is alive, but I also realize that we might want to for example offer writing that cache to disk so that for example invoking the curl tool repeatedly can get use of it...
what would be really nice is a libcurl interface that allows me to supply alternatives to a host (perhaps as part of a curl easy/multi handler) - then I can chose to manage the Alt-Svc's using the "Stenberg cache", or one provided by my system, or one I wrote myself.
Aaaah right. Like CURLOPT_RESOLVE and CURLOPT_CONNECT_TO but slightly different (again) =)
I'm not opposed that idea, but I also don't think we need to do that as part of the first implementation. It feels like more like step 2 or 3 if someone is willing to put the work in to make something like that. I think it takes a solid use case that isn't by then properly covered by the existing altsvc cache functionality.
I'll expand the wiki page somewhat to reflect this. -- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
