On Thu, Jun 2, 2011 at 17:36, Greg Stein <gst...@gmail.com> wrote: > On Thu, Jun 2, 2011 at 09:30, Julian Foad <julian.f...@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
