On Thu, Jun 2, 2011 at 17:36, Greg Stein <gstein_at_gmail.com> wrote:
> 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.
>
+1.
--
Ivan Zhakov
Received on 2011-06-02 15:41:35 CEST