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.

> 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.

> 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.

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.

> 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.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html