Hi, Daniel, On Sun, 21 Sep 2014, William Grim wrote: > > Hi, I'm interested in exploring what level of cache support we can get > added. > And how. Like for example the library approach to storing the cache and the > cache index etc is interesting. >
I was just going to do very basic caching, storing downloaded assets onto disk in an area the user specifies. Or, with regard to public Cache-Control, I would use a common area like "/tmp" or some other place that syscalls tell me where the temp dir is or some other user-defined env var or something. I haven't decided storage locations really. > > > Now, my topic of interest is with regards to caching. It looks like > libcurl > > supports no HTTP caching mechanism, and I was thinking about implementing > > one. It will not be 100% HTTP RFC-compliant by any means, since our > company > > doesn't currently have a need for the full spec. Besides, we have some > > custom work that will be done for the purposes for security. > > Incomplete is actually fine, as long as what we implement is RFC > compliant. I > think deviating from the spec path is a really bad start. Especially since > I > believe the updated HTTP RFC is now much improved and clarified in this > area. > Okay, anything I create and pass back to libcurl will be the RFC-compliant portions then. However, on the topic of the HTTP RFC, rfc2616 is the original, closed version of the RFC. Are you referring to rfc723x? I admit I have not read it, but I will do that and try to follow its guidance. > > > Finally, I come to the question. If I introduce a caching mechanism > > directly in libcurl, even if it's not fully HTTP compliant, would the > > libcurl devs be interested in accepting something like that back? > > That's a very open queston and I can't promise we'd adopt it. Apart from > the > code, we would also want docs and test cases so that people can actually > figure out how it works and we can run tests and make sure that the > funtionality remains even in the future. > That's no problem. I often provide stuff like that for my colleagues; so, I can work with the libcurl devs to get them what they need. > > I also think that we would have to allow caching to be conditionally turned > on/off in a build since I expect that there will still be a large user > share > who won't care the least about caching. > Of course, this is right. I had only thought about enabling/disabling it via curl_easy_setopt, but a compilation flag also makes sense. > > > since there's no caching model currently in place, is there a reason for > > that other than just no one has ever done it? > > No one has ever done it, and I've also considered it a piece of the HTTP > stack > that is less wanted by our typical users and even that it could be > implemented > "on top" of libcurl rather than integrated into it. > You're right that everything can be implemented on top of libcurl. In fact, this is the approach I was originally going to take at my company. However, this has to be something people want, and I feel a lot of people have probably reinvented the wheel several times to get this. In the interest of developer efficiency, that's why I'd like to offer something for you guys. Also, I take it that your preferred method of proposed submissions be in the form of GH pull requests? Thanks again, Will
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
