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

Arrh! dirty habits... ;p

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

Well I must admit I'm completely unaware of what is being worked on your
side.. Is there a place were I can read something about that?

 Anyway I tested it and it works fine (as far as you make the cookies
pointer NULL after cleanup :). I may keep this until a better way is
available.

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

It sounds nice.. ;)

Cheers.
Lo.

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