On Thu, 19 Oct 2006, Jamie Lokier wrote:

>> Correct, we need to invent a way to tell libcurl that we're not interested
>> in getting anymore (data) from a specific transfer, and of course be able
>> to again enable the flow. This goes for transfers in either direction.
>
> An alternative model is to do it like asynchronous I/O calls:
>
> 1. The app sets its callback; this is equivalent to "async_read".
> 2. The callback is called _once_ when there is data; this is completion.
> 3. When the app is ready to receive more, it goes to step 1.
> It would do this immediately after step 2 to get the current behaviour.

Yeps, that's one way to do it. There's however at least one little drawback
with this approach, and that is that with the current libcurl when you
"disable" a callback by setting it to NULL, it switches to the internal
default callback instead... And changing that would break the existing
behaviour.

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