On Tue, 11 Jun 2002, Tom Mattison wrote:

> > You need to make one of the callbacks return an appropriate return code
> > to make curl stop. There is no other way.
>
> On ftp send, I wasn't using the read callback, but its easy enough to
> switch over to it. Am I correct to assume the read callback won't get
> called util a connection has been established?

Yes.

> Will the read callback ever get called if there is some problem connecting?

No.

> I guess I'm at the mercy of the system timeouts as far as waiting for a
> connection or an error to occur (I'm using a worker thread to send files to
> prevent blocking).

System timeouts by default, curl_easy_setopt() timeouts if used/available.

> Have you given any though to establishing some sort of communication state
> notification callback?

I have two independent "ideas". One is to have the progress meter callback
getting called already during the connect phase. This would then allow you to
abort a transfer early enough using only the progress meter callback. This
wouldn't even be a very big change.

I also have another idea that I kind of like that that is such a
"communication state notification callback" you mention that would be called
when reaching different "states" in the communication. It could be used for
UI displays or transfer debugging or whatever. This is a slightly bigger
change. I'm not entirely sure this really is worth adding if we make the
progress meter callback work as above.

> (I see in the docs that the progress meter is going away at some point.)

That refers to the internal progress meter output, not the callback itself.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink