On 29 Jun 2017, Daniel Stenberg 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!

I agree. Start simple!

> > 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 agree it is probably a step 2 or 3. My general use case is where there may be more than one HTTP client on the system; perhaps even multiple instances of libcurl based clients. I guess that what I think is important is that libcurl doesn't take sole responsibility for managing Alt-Svc and keeps me in the loop.

In one use case, I'd like to take away some of the responsibility for Alt-Svc cache population away from my main application code, for example, I'd like a pre-seed phase where a light weight application populates (or revalidates) an Alt-Svc cache.

In a different use case, I need to use a HTTP-like protocol that libcurl doesn't support yet (QUIC for now but that will change ;)) and need to hand off to a different library when I decide to switch protocols. In the other direction, the other protocol may contain Alt-Svc I need to process.

Regards
Lucas

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-07-10