On Mon, 5 Dec 2005, Legolas wrote:

> As a very bad example, give a look to the client pseudo code I have written
> taking in account what I have read up to now. I have also put in it my
> original idea in a soft way. However, that's not my idea, it's just an idea
> :)

Thanks a lot for the "mockup".

Now I can see how this suggestion is similar to my original (in text)
suggestion: libcurl calls a callback to request a buffer to store incoming
data in. The 'at least this big' argument is indeed needed.

Some further comments/ideas:

Upload

   We also need to cater for uploads, where the current code calls a read
   callback with a buffer pointer to have the application copy data to it. To
   turn that into zero-copy, it would need to be done in a way that allows the
   application to instead pass in (return?) a pointer and size with data to
   upload.

File-write case

   In your example psedo code you have two use-cases, but for the scope of this
   discussion I'd say you can ignore the (1) case when the app simply wants to
   download directly to a file, as then I can't see hwo we can avoid copies
   more than we currently do (using the libcurl internal fwrite() code).

Write callback

   Your example also has a modified write callback proto, and while we can
   certainly have that we should not re-use CURLOPT_WRITEFUNCTION for the new
   meaning. I'm a bit curious about the 'writable' argument. What purpose does
   that serve? Also, the check the callback currently does for if the buffer
   is its own (SB_IN_RANGE) really can't be used like that, as that will be
   really painful for the cases where the application for example decide to
   keep download data in a linked list of chunks or similar. It would be much
   more elegant to either have libcurl specify in the invoke if the buffer is
   user-provided or libcurl-provided, or just never call this callback with
   anything else than user-provided buffers.

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