On Thu, Jun 02, 2011 at 05:40:41PM +0400, Ivan Zhakov wrote: > On Thu, Jun 2, 2011 at 17:36, Greg Stein <gst...@gmail.com> wrote: > > 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.
Then we need to move the functionality out of the stream code and into the patch code. Which is fine with me but this would be a release blocker since it involves changes to the public API and I don't know how fast it can be done. The patch code uses this quite heavily.
