Daniel,

views as requested:

> 1. File locking. It was said we need file locking to have several invoked
> curls all write to the same destination file. I have serious doubts
> around this. Not only do I suspect that people will still make mistakes
> when using a single output file, but we'll also get problems with systems
> that don't do proper locking (like various OSes or just systems running
> on NFS or similar).
>
> 2. Cookie filtering. Are we gonna support that somehow? How would one want
> to filter cookies? On sending and/or receving cookies?

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:)

The main benefit I would see is the speeding up/proper handling of the
selection of the appropriate cookies from the jar on a per-request
basis, and the handling of the rules which say what cookie should be
replaced/updated/deleted when new cookies arrive or old cookies expire.

Actually, we have a generic 'per-header' callback all ready, and its no
trouble to see each cookie arrive at that point - 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'm currently using HTTP::Cookies.pm to do this kind of function, and
asking it not to save/load the jar (just making the cookie jar object
persistant), because I don't want to use a flat file, but locking is
still important - I have to do a read-modify-write cycle on the whole
master jar whenever I have an updated cookie, because multiple threads
can be reading/writing simultaneously.
Received on 2001-08-29