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
Received on 2014-09-22