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