None please. My vote would be to put caching in a separate library that
wraps the existing mean-and-lean curl. That way people like me who require
straight-shot, non cached transport don't need to worry about it. Fewer
build options, less code to worry about. Just an opinion.

- Chris

----- Original Message -----
From: "Walter J. Mack" <wmack_at_componentsw.com>
To: <curl-library_at_lists.sourceforge.net>
Sent: Friday, September 20, 2002 6:37 PM
Subject: RE: Cache in curl (edited verbose junk) please express yourself...
:-)

-----Original Message-----
From: curl-library-admin_at_lists.sourceforge.net
[mailto:curl-library-admin_at_lists.sourceforge.net]On Behalf Of Lorenzo
Pastrana
Sent: Friday, September 20, 2002 2:51 PM
To: curl-library_at_lists.sourceforge.net
Subject: Cache in curl (edited verbose junk) please express yourself...
:-)

These days I try to not add things to the library without getting a feel for
what people actually want.

Quick poll :
What cache mechanism (if ever) would you like to be added to curl?

[X] None thanks.
[ ] Strictly validated
[ ] Full blown HTTP1.1 fuzzy logic
[ ] Don't care ...

Argumentation :

> Caching is clearly very detailed in RFC2616.

Actually what I mean by cache is a simple web client facility.
Of course, delivering correct content to the client is a MUST.
The rfc states about all that.

For purpose of correctness, from what I read in the rfc,

- TIMECONDITION is a perfectly legal cache validator (a 'weak' one though,
if we can call it so, due to the 1 second resolution of time data :).

- ETag management (thru If-match / If-None-Match request header) is also
required, this one is a strong validation. I'm working on it too.

There are no other 'validation' methods.
All others Headers/Params are ment for the cache to be able to decide wether
asking the origin server for validation or not.

<cache behaviour proposal>

Of course supporting the full blown cache related bells & wistles included
in HTTP1.1 is necessary for completely optimal caching (witch is ment to
prevent systematic validation request to the origin server). But here I
believe that if I can just avoid the download of the body part I'll be
happy, and best of all : quite sure that what I get is valid content. All
other methods (based on expiration) implies assumptions and heuristics that
can lead to very annoying situations, especially when you're a developper.
However, this being a matter of taste, I think we can consider adding some
"Expires:" response header management as an option; but delivering a
non-validated cache file would preferaibly be some sort of fall-back
solution in case of off-line operation/network-error ...

</cache behaviour proposal>

Well, I hope the furious snipping was worth the effort ;)
We need your feedback!

Lo.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-09-21