On Fri, 7 Aug 2009, johansen_at_sun.com wrote:

>> Ah, no. I wasn't paying enough attention. You're right, that's for the
>> read stream... Perhaps we need to add a similar one for the write stream?
>
> I wondered the same thing myself, but I don't have enough experience to make
> a broad generalization. I don't see any code or documentation that forbids
> users from passing a FILE * to CURLOPT_WRITEDATA that has been fseek'd to a
> different offset in the file. If we write a method that seeks back to 0
> when Curl_do() loses the connection, then we'll break the ability for users
> to do that. On the other hand, it seems like a bit of a contrived case.
> However, that case lead me to consider simply returning an error to be a
> better approach. (It's hard to anticipate what the library's callers might
> be trying to accomplish).

Indeed. If a write seek is deemed necessary, we'd have to do it like the
SEEKFUNCTION so that libcurl asks the app to seek with a callback, but the app
might not be able to either for example in the case it simply passes along the
data like in a pipe or similar.

> I'll try a couple of different approaches. I will send out an updated patch
> once I find something that works well.

Great!

> OpenSolaris is making use of this code pretty heavily now. We picked
> libcurl for the packaging client because it allowed us to perform pipelined
> downloads.

Out of curiosity, did you measure how much impact pipelining has on your
typical use cases in terms of speed?

-- 
  / daniel.haxx.se