> > Do you want to go back to TRUE/FALSE ?
Yeah I already got the point :)
I dont mind in fact. I was just waiting for an acknowledgement. I'm happy
with the meaning of the true/false (option A) already. (Yes I dont need a
lot to be happy I must admit)
The main info is in the true/false : true says yes libcurl used one (or
more) time an already connection, false if libcurl had to make a connection
at least once. Personnaly it's what I need.

I was just wandering if there's a point for other states. The third state
saying finally only 'mixed case' : libcurl reused the first connection but
had to make at least a new one as well. This is a really poor information
it's why it maybe doesnt worth the coding but hey using true/false on a long
is also a waste a space :)

> What would the option say about connection re-use? If it would say "first
> re-use then new", one might get the idea that the original connection to
host
> A is still alive, when it in fact isn't since we only keep 5 connections
alive
> and we got 5 others in there now.
Hmm I dont think so anyway because the REUSED_CONNECTION 2 or 3 state flag
says something about what happened and not about the future. We dont know if
the first, second, n-eme connection is not closed simply because the server
closed it (ok we could know by looking at the headers of the response and
then guessing because of this flag that the connection is still open but I
dont think that expecting a connection to be open before really using it is
a good idea anyway, connections may be broken/reset etc...)

If we still want to debate on a third (or more) state I can also propose
something more clever mixed with CURLINFO_REDIRECT_COUNT.
option B) use the bits of the long :
each bit for each redirect saying
0 -> had to create a connection
1 -> reused a previously opened connection
PRO : a long is always sufficient
CON : limited to a number of bits used to store the info but I doubt that
more than 10 redirects will happen often :) (had to force the maximum of
redirects + a host that does that !)
(and MAXLONG reply may say 'sry too many redirects')

option C) simply an array of char with CURLINFO_REDIRECT_COUNT cells.
each cell = 0/created or 1/reused
PRO : clearer than the solution above, unlimited (or limited to a constant
to avoid memory reallocation after each transfer ?...)
CON : some octets used :)

Let me know for which option A, C or even B you re up.

And if needed your wish about enums/simple defines for the long/char
----- Original Message -----
From: "Daniel Stenberg" <daniel-curl_at_haxx.se>
To: "libcurl development" <curl-library_at_cool.haxx.se>
Sent: Wednesday, October 13, 2004 5:58 PM
Subject: Re: Flag to know if the curl object used
apreviouslyopenedconnection

> On Wed, 13 Oct 2004, Guillaume Arluison wrote:
>
> >> Perhaps the info should be "did libcurl need to create a new connection
to
> >> do the request?". It would be a lot easier to answer yes or no to, even
if
> >> one or more redirections occurred.
>
> > Well in fact I did only the TRUE or FALSE at beginning which means
exactly
> > that, I just thought that because we re using a long anyway we may use
more
> > 'bits of information' like the 'libcurl used an existing connection but
> > because a follow finally had to recreate one.' Anyway this isnt really
an
> > important information (in this case the REUSED_CONNECTION will be FALSE
> > instead of the 3rd case) and it was just a try to give more information
to
> > the user.
>
> > Do you want to go back to TRUE/FALSE ?
>
> Consider this case:
>
> You have a previous connection to host A. You do a second request to fetch
a
> URL from host A and tells libcurl to follow redirects. This time you get a
> redirect to host B and it gets redirected to host C etc all the way to
host F.
>
> What would the option say about connection re-use? If it would say "first
> re-use then new", one might get the idea that the original connection to
host
> A is still alive, when it in fact isn't since we only keep 5 connections
alive
> and we got 5 others in there now.
>
> I'm just asking you (and anyone else) if the three different replies
really
> are meaningful or if they are more likely to just add confusion to users
by
> providing useless info.
>
> I'm just asking, since I'm sure I don't see all the quirks and pitfalls.
If
> you can think of a use for this extra and explain it, I'll approve.
>
> --
> Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
> Dedicated custom curl help for hire: http://haxx.se/curl.html
>
Received on 2004-10-13