On Sat, 11 Aug 2007, Robert Iakobashvili wrote:

> I would agree with Davide, that it is better not to have API with
> overloading of functionality.
> add - should really add,
> remove - should really remove

Yeah, you're (both) right. We'd need to add a new function for this to get
done right.

> There are two major user scenarios here:
> a) restart transfer using a handle with the same URL, etc as for the
> previous transfer;
> b) re-use the handle for another URL (could be after http - ftp), or other
> params;

Yeps, but case A above is probably not very common...

> case a) may be handled by some curl_multi_restart_handle ()
>
> Case b) requires:
> 1) reset an easy handle;
> 2) setting a new URL, new params to an easy handle;
> Still it does not work without correcting states.
> It looks like function curl_multi_restart_handle () might be of assistance
> for this case as well.

We could add a curl_multi_restart_handle().

The only objection could possibly be that today an app is basically expected
to detatch the easy handle, set new options and re-add it. It means that the
easy handle is not attached to the multi when it gets options set.

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.

Also, we need to consider how to react if an app calls
curl_multi_restart_handle() in the middle of a transfer.

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