On Wed, 29 Aug 2001, Cris Bailiff wrote:

(This mail is a reply to a mail in the curl mailing list, although CC'ed to
the libcurl list as we're moving into library territory here...)

> As I'm using mainly the library (not the command line tool), I don't want
> to store the cookie jar in a flat file, I want to store it in some
> database somewhere (memory, sql, whatever - currently a perl array), and
> be able (ideally) to pass the whole jar in for curl to pick and choose
> based on the request URL, and at the same time, get a callback
> (filter...) whenever a new cookie is received (set-cookie:)

I deliberately left out library issues from the discussion in this mailing
list, as I want them to be held in the libcurl mailing list. We have more
than one hundred subscribers of each list...

> I was really more interested in getting more information about the
> updates required - I'd like to be told 'delete this cookie', 'add this
> cookie to the jar', 'search for cookies matching XXX' then I could get a
> highly concurrent cookie store and I can take care of locking the
> 'master' copy of the jar to add the new cookie in the callback etc. The
> 'search for cookies matching XXX' seems likely to be the hard bit :-)

I would have no problems with offering a set of callbacks (or similar) that
would offer more or less the above. Would these callbacks then replace the
internal cookie storage or would it serve as a complement?

I have been thinking about a slightly different approach, that might fit even
more users: the "separate" cookie jar.

It would offer an interface that is not connected to a particular curl handle
[*]. You init the jar, load existing cookies from file(s) and then you
"connect" the jar to a curl handle that will then use the particular cookie
jar to fetch cookies from (to use in requests) and send cookies to (when
they're received in response-headers).

The cookie jar interface would offer callback hooks to get information about
specific cookies, for filtering and for saving cookies to flat files.

The cookie jar would require lock callbacks to be set (by the libcurl using
applicaton) for multiple (simultaneous/asynchronous) accesses to work.

This obviously needs more thinking. I'm just trying to say that there are
many different routes we *could* take...

[*] = It needs to be separate from the normal "handle" to have a theoretical
      chance of surviving in a multi-threaded environment.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/