>> The only API improvement I would propose could be a function that changes
>> the multi state from the blocking states (CURLM_STATE_COMPLETED or
>> CURLM_STATE_CANCELLED) to the state CURLM_STATE_INIT, doing the various
>> initializations; a sort of fusion of remove/add functions without the linked
>> list management.
>
>I've been pondering on allowing curl_multi_add_handle() on an already added
>handle to do exactly that: reset the state and thus restart the transfer.
>Currently, calling curl_multi_add_handle() on an already added handle will
>result in CURLM_BAD_EASY_HANDLE getting returned.

That sounds even better and consistent as you couldn't reset a handle
not being already in the multi handle... the only drawback is backward
compatibility, maybe someone relies on that add_handle() behaviour.
You may add a parameter to the current function to select between the
two behaviours, and make it private; then you may provide two separate
wrapper functions, for example:

curl_multi_add_handle() : behaving like before, not breaking compatibility
curl_multi_add_or_reset_handle() : doing reset / init of an already
inserted handle.

Maybe too API cluttering?
Just my 2 cents anyway :)

Davide
Received on 2007-08-11