🚀 go-pugleaf

"Bill D. Pirkle" <mbpirkle@NOSPAM.att.net> wrote in message
news:41c74be0.158720888@newsgroups.borland.com...

> Now I need to use cookies with some of these sites.  I know I need
> to attach a TIdCookieManager to each TIdHttp object (and make
> sure that AllowCookies is true).

By default, TIdHTTP instantiates its own TIdCookieManager internally if you
do not provide your own.

You do need to make sure the AllowCookies property is set to true.

> My question is:  should I dynamically create a separate cookie manager
> for each thread?

Unless you have some compelling reason to share cookies across threads, then
you should use separate instances.

> Or should I use one master cookie manager that all the threads
> share?  If they share, are there any simultaneous access worries
> that I need to sort out?

TIdCookieManager provides its own thread synching internally.

> The advantage of sharing would seem to be that if I need to carry on
> an extended conversation with a particular server, the shared cookie
> manager just magically handles everything.  So (for example) I might
> need to download and display info, wait for a user response, and then
> do more communications with the Web server.  The Web server
> should see this as the same user session.

Why would you need a shared manager for that?  If a single thread is
handling the entire conversation, then a local cookie manager would handle
all of the cookies for that conversation.

> With a shared cookie manager, my hope is that everything would be
> okay, even if I use different thread (and therefore different TIdHttp)
> objects for the different phases of the conversation.

Why would you use different threads to handle the conversation?


Gambit