Daniel Stenberg ha scritto:

> 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".

Nope :) some C rows are more clear of hundreds of plain english rows
(also consider that I am not very good in this language).

>
> 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.

Yeah, but in the beginning I wanted something like 'simple_buf'
available directly in libcurl (a sort of 'curl_buf'), with more
attributes in it also. About the argument: my doubt was about the
editable property of the 'desired_size' argument: should the library be
aware if the buffer is somewhat greater than required? I think yes.

> Some further comments/ideas:

(They're welcome)

> 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.

To be continued...

> 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).

It was a silly example, I was just painting the case an application
needs only to "look into" the buffer. I should also make an example of
an application looking for a string, but would have been a little bit
more complex...

> 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?

As suggested by J.Lokier, application may need to make in-place editing
also into library buffers, and we can allow this if the library buffers
are going to be cleared in the next operation.

> 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.

Yes, it was a *very* dirty approach. I will soon send a modified version
which also covers the third type of application (using a simple linked
list of chunks). I will also try to specify some parameters as
attributes of the 'simple_buf' structure, and also to specify the ownership.
Received on 2005-12-06