On Thu, Jun 2, 2011 at 09:30, Julian Foad <[email protected]> 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
