On Sun, 12 Aug 2007, Robert Iakobashvili wrote:

>> If we add curl_multi_restart_handle() it pretty much relies on the fact
>> that after a particular easy handle has completed a transfer, you change
>> options of it while it still is connected to the multi handle, and then you
>> restart it. I'm not saying we can't do that, just that it makes the usage
>> someone different.
>
> Yes, this is a different usage mode to be described and documented in due
> course.

We could possibly also make curl_easy_setopt() refuse to work if the app is
setting options to it while it is "in progress". I haven't really made up my
mind if it would be good or bad...

>> Also, we need to consider how to react if an app calls
>> curl_multi_restart_handle() in the middle of a transfer.
>
> Good point. The first hypostases of the function may return an error, when a
> handle is in the middle of a transfer.

Yea, or it could act exactly like a remove/add handle would do, which is to
abort and reset the transfer from the start. A separate argument to the
curl_multi_restart_handle() function could be considered to select which the
behaviors that is desired.

> Canceling a transfer in the middle could be another sophistication and a
> separate issue, like curl_multi_stop_handle() ...

Yeah. This made me think on instead providing a single function like:

         curl_multi_handle_control()

That can get get told to control the easy handle (while) added to a multi
handle in various ways:

- RESTART, unconditionally restart this easy handle's transfer from the start,
re-init the state

- RESTART_COMPLETED, restart this easy handle's transfer but only if the
existing transfer has already completed and it is in a "finished state".

- STOP, just stop this transfer and consider it completed

- PAUSE?

- RESUME?

These are still just ideas and brainstorming...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html