On Mon, 16 Sep 2002, Lorenzo Pastrana wrote:

> Well, it seams pretty easy (at firsh sight) would something like this
> suffice?
>
> void curl_easy_flushcookies(CURL *curl)
> {
> struct SessionHandle *data = (struct SessionHandle *)curl;
> // pasted from Curl_close.

No C++ comments here please. ;-)

> if(data->set.cookiejar)
> /* we have a "destination" for all the cookies to get dumped to */
> Curl_cookie_output(data->cookies, data->set.cookiejar);
>
> Curl_cookie_cleanup(data->cookies);
> }

> That would imply a new explicit cookie initialisation (cookiejar and/or
> cookiefile) for further use of the handle is needed. But that is precisely
> the point : decoupling cookie management & handle lifetime.

While I agree with the general idea, this somewhat collides with the "share"
stuff that is slowly being introduced (Sterling Hughes works on it), and I'm
not sure how we should deal with this.

I mean, both ways introduce new function calls to the API so I would probably
instead prefer the full and complete share system that will allow this to be
solved differently.

Using the upcoming share system, you create a 'share' object and you tell
what kind of data that should share and then you tell a handle to use that
share object. That would include cookies. So, if you would your handle to
stop using the cookies, you would again remove that share object from the
handle.

The share object would also have lock and unlock callbacks to be able to get
used from different threads.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf