On Tue, Feb 2, 2010 at 4:34 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 2 Feb 2010, Nick Jensen wrote:
>
>> I've attached a small patch for curl-7.9.17 which is based on the
>> connect-progress-2.patch created by Dan Stenberg that is posted here
>> http://curl.haxx.se/mail/lib-2010-01/0077.html
>
> Thanks for your interest and will to help us improve libcurl. I'm however
> far from convinced this callback is what we need.
>
> Can you elaborate on the use-case you see this providing a useful value for?

It is a rather specific case, one that applies to an application that
I'm working on though. Nothing that I expect to be included in the
main line of libcurl or anything. I just wanted to post it in case
someone else is also interested.

To me it is just a separation of logic. For example I have a delegate
method that I would like to be called during the connection process at
the beginning of a transfer (or multiple transfers) where I can do
notifications etc, and then a different delegate method that does
progress and speed calculations.

>> Basically instead of invoking the progress callback during the connect
>> process and sending 0 values for all the speed arguments, I've created
>> a couple new curl options called CURLOPT_CONNECTINGFUNCTION, and
>> CURLOPT_CONNECTINGDATA. Using these will allow you to delegate
>> progress info and connect status info separately in your applications.
>
> In reality, isn't the current callbacks 0 values basically the same as
> "still connecting" ?

Not necessarily. I've seen all 0 values come into the progress handler
if I'm doing a recursive upload/download and a zero byte file is
somewhere in the mix.

>
>> The function gets invoked after DNS resolution when curl tries to
>> connect to an IP address.
>
> But why after DNS resolution? So it'll first call the regular progress
> callback N number of times with a 0 value, then start calling the connect
> callback?

No. The connecting callback is always the first one to be called. Like
I said, this was based on your original patch that invoked the
progress function during the connecting process. I simply made it a
separate function that gets called instead. The progress function is
only called during progress. If I were to log the order in which
callback methods were invoked, the flow would look something like
this.

perform(curl);
connectingCallback:status:0
connectingCallback:status:0
connectingCallback:status:1 /* success */
uploading:1%
  ...
curlReturned:CURLE_OK

Or if the connection timed out.

perform(curl);
connectingCallback:status:0
connectingCallback:status:0
connectingCallback:status:0
  ...
connectingCallback:status:2 /* timed out */
curlReturned:CURLE_COULDNT_CONNECT

> Another detail: what is "connecting" really? I figure you'd need
> to specify that this is the actual TCP connection handshake we're talking
> about, as many application layer protocols have a "connect part" that users
> may consider be part of the connect phase.

Yes that could be made more clear.

> Also, when connections are re-used that callback is completely skipped over.

Yes. For my particular case that is desired. Not sure what other users
would want.

> Another little detail: the current CVS has changed those parts since 7.19.7
> so I doubt your patch applies cleanly.

If anyone is interested I could look at applying it to the latest
source tree. Just thought I'd share my efforts either way.

--
nick jensen
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html