🚀 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

Thanks for the reply, Remy!  Comments follow:

On Mon, 20 Dec 2004 15:51:00 -0800, "Remy Lebeau \(TeamB\)"
<no.spam@no.spam.com> wrote:

<some helpful comments snipped - thanks for the info>

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

I think you mean why would I use different thread to handle the "first
part" and "second part" of a conversaion with a particular site.
Maybe I shouldn't.  

In case you meant why would I use multiple threads at all rather than
having a single thread handle all communications with all sites, the
reason is to minimize the user's wait time by doing communications
with various sites in parallel.  But as the thread code I'm using was
stolen from a file-download example posted by you that uses multiple
threads for exactly this purpose, I'm pretty sure you meant the first
interpretation.  I'll go with that for the rest of this reply.

Here's the overall flow the app:

1)  app scrapes data from several different specific Web sites (around
a dozen, maybe more.  But not thousands or anything.)

2)  app consolidates returned data and presents it to the user

3)  user stares at data for an indeterminate amount of time and
(maybe) chooses to view additional data from one or more of the source
sites.

My first instinct with the threads was to create them when the app
needs to talk, then kill each thread off as its data comes back.  Then
if the user later wants more data from any of the sites, create more
threads at that time.  That way, I don't have to keep up with a bunch
of threads sitting around suspended just in case they might be used
again.

On second thought, keeping the threads around (or at least their
associated Indy objects) is sounding like a better idea.  I can just
create a Site object to wrap each one and provide a nice, clean
interface.  I'll need a Site object anyway for various bookkeeping
purposes, so adding thread object management wouldn't be much more.  

The reason I posted the question in the first place was to make sure I
used as much of Indy's built-in magic as possible.  I'm not that
familiar with Indy yet, and I'd hate to recreate something that it
already takes care of.  It looks like multiple cookie managers is
probably the best way to leverage Indy's functionality, so that's how
I'll go.

Thanks again, Remy!