On Thu, 30 Jan 2003, Dave Halbakken wrote:

> I'm using curl version 7.10.3 release with MSVC6 on Win32.
>
> I'm attempting to change libcurl's read-callback function and read-data
> pointer on an open connection. I'm able to make this work for
> write-callbacks and write-data pointers, but not for reads.

I suggest you do not do this. If you want to change behavior in the middle of
a transfer, I suggest you do a switch() or something in the callback of your
choice.

> There appear to be two copies of the read pointers:
>
> conn->data.set.fread and conn->fread
> conn->data.set.fread_in and conn->fread_in

Correct. The values set by the application is stored in a single place, and
the values actually used are elsewhere. If you keep on digging in the source,
you should soon find out why and also see that "fixing" this is not easily
done, and I would say no very wise.

libcurl changes the used read-callback values by itself internally when
dealing with data that is being sent (multi-part formpost or even just
ordinary HTTP requests that are too big to get sent in one single chunk over
the network).

> The behavior for writes appears to be different. It looks as if there is no
> duplication of the write pointers
>
> Libcurl appears to use the values directly from conn->data.set during all
> operations, so when you call curl_easy_setopt on an open connection, they
> get used immediately/

Write is different as there is never any need internally to change these
values.

> I'm not sure what to do about this. I can code around the problem outside
> libcurl, but it would break the encapsulation I've setup. I'd rather see if
> this can be fixed in libcurl so that the behavior is the same for both
> reads and writes.

You mean fixed as in we make sure that we can set the read callback to new
values in runtime? Well, it could be done but until you show me the huge
benefits from adding this, it seems like wasted time and efforts to me.

> Is there a good reason for duplicating the read pointers and subsequently
> ignoring the ones that get set by curl_easy_setopt after the connection is
> created?

IMHO, it is very good. But for a greater understanding of this, I suggest you
run test case 56 and consider what happens in libcurl when that runs! :-)

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com