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
