On Thu, 16 Jan 2003, Philippe Raoult wrote:

> > I think you're oversimplifying this. There is a reason why libcurl
> > collects header lines into one single buffer: it needs to be able to
> > check headers for specific contents, why it needs to construct full
> > headers before those checks are made.
> >
> > But if you have a way to overcome this "problem", then please tell us!
>
> we talked about this with Laurent and i told him to post here because we
> hadnt been able to find any clever way to get out of this. I agree that
> passing raw headers is bit simplistic. The way i see it, BUFF_ALLOC allows
> the user to specify a malloc function to curl. It follows that either :

> - the user also has to provide a free function for curl's internal use (and
> a realloc one too)

> - the provided malloc should only be used when data is actually passed to
> the user.
>
> I'd rather stick with the latter solution because the interface is supposed
> to be about not copying data around, and certainly it wouldnt help to use
> the whole malloc/realloc/free for curl's internal use.

I agree with this. Replacing the malloc/free calls for all libcurl operations
won't help you at all to work out a nocopy API.

> I thus propose the following logic:

> * what is passed to the user from curl via the WRITE callbacks should be
> allocated with the provided BUFF_ALLOC function.

And I guess this alloc is performed basicly before each call to read() in
libcurl? So that the application could for example have a large amount of
pre-allocated buffers and hand out one at a time when libcurl asks for one.

> * this means that if the user provided a HEADERWRITE function, then the
> header buffers *which are passed to it* will be allocated with BUFF_ALLOC

Right, and if libcurl needs to realloc that block? Then it will need to do
some kind of realloc magic...

> * same goes for data WRITE, but there it is easier

> The easy part is already done, and (I || Laurent) will do the rest when we
> have reached an agreement on what exactly to do.

Right. Also, we can always bounce some more ideas and fixes back and forth
once you guys present the first working patch.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en