On Thu, Jun 2, 2011 at 09:30, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Wed, 2011-06-01 at 17:29 +0200, Stefan Sperling wrote:
>> On Wed, Jun 01, 2011 at 11:15:16AM -0400, Greg Stein wrote:
>> > The "few" that I was talking about were the "skip" and "mark"
>> > concepts, too. Those seem to be very specialized, and maybe only used
>> > by the "patch" code?
>
> Oh, right.
>
>> They are only used by the patch code. They are used while reading content
>> from the patch target which can either be in a file or in memory (in
>> case we're patching a property). So the stream abstraction is useful
>> there but the patch code also requires seeking capabilities.
>>
>> We can make these APIs private if you like. Though I guess other clients
>> might find them useful, too. We'll have to support this code anyway
>> as part of the patch implementation.
>
> I've made the is_buffered() API symbols private in r1130538.
>
> Not sure yet about the others. "skip" is a pretty simple concept,
> functionally equivalent to "read" but discarding the result, or
> alternatively equivalent to "seek(..., SEEK_CUR, offset >= 0)". So
> we're introducing limited forms of seek: seek to beginning, seek to
> previously marked point, and now seek forward by N bytes. I don't know
> whether that's too much clutter for a stream implementation or not.
Well... note that the stream concept is used rather than apr_file_t
because "we may want to use something besides a file, in the future".
IOW, these extra APIs are for unproven future need.
I might also argue for something like:
svn_seekable_create()
And the associated 'svn_seekable_t' has the various forms of seeking.
It could consume a string, or a file, and it could also use the same
kind of read/write callback types. But it would have functions that
svn_stream_t does not have. A "stream" is generally not seekable,
under any interpretation of the word.
Cheers,
-g
Received on 2011-06-02 15:36:39 CEST