On Mon, 10 Dec 2007, Georg Lippitsch wrote:

>> We could possibly introduce a new CURLOPT_IOCTLFUNCTION version (with a
>> different) name that would support both the existing rewind system (and it
>> could get a value as well) and your new fast forward system.
>
> But that's what I actually did, the fastforward function could of course
> also be used to rewind. If it is used for that purpose, it should probably
> just get another name (CURLOPT_SEEKFUNCTION or whatever).

Yeah the name "fast forward" a bit misleading. SEEKFUNCTION sounds more
appropriate!

And also, the current ioctlfunction callback code that does rewinding should
use this new function (if present) in preference to the old one if we want to
be able to let application migrate nicely to the new callback! But that also
makes me consider if the seek callback would be better with a 'whence'
argument just like lseek() has (to do a relative or an absolute seek), as in
the rewind example for example we want it to seek back to the start and I'm
not 100% sure we care enough and pass around the number of bytes actually read
so far, or at least it may not be clear to the application how much libcurl
thinks it has read. Being able to tell "seek back to index 0" is much less
error-prone in that case.

> I'm also thinking of implementing a default fastforward/seek function that
> uses fseek, but this is tricky because not all streams support seeking (even
> if no custom readfunction is set). We could possibly add this default
> function for convenience but not set it by default ... What would you
> suggest?

Nah, I think we should ignore seeking by default since most applications won't
be using plain default seekable streams anyway.

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