Julian Foad <julianf...@btopenworld.com> writes: > The point about the generic stream API is you should always be able to > define a new stream class that wraps a stream (examples: a 'tee' > stream wraps one stream while copying to another; a checksumming > stream, etc.). > > And you should always be able to use the wrapping stream in place of > the original stream. > > The 'svn_stream_flush_to_disk_on_close()' that you suggest breaks that. > > The implementation you suggest in your email an hour ago needs direct > access to the implementation methods of all the stream classes that it > may possibly encounter (close_handler_gz, for example). > > And functionality supported by streams should be provided as a virtual > method, overridden in each stream class. > > Like Evgeny argued in his first email in the thread, > http://svn.haxx.se/dev/archive-2015-05/0154.shtml > > He then proposed a virtualized method 'svn_stream_flush()' which > solves the abstraction/virtualization issue. > > But then you have to define abstract semantics for 'flush', which that > attempt didn't do well. > > It just doesn't all seem to fit together, the idea of telling a > generic stream "you must ensure the result of this generic stream > processing is written to *a*/*the*/*which?* phyical disk". > > For example, should a 'tee' stream ensure that *both* output streams > are flushed to disk? That's a rhetorical question: the point is there > is an semantic mismatch.
The argument appears to be that we cannot design a perfect stream library and so we should write code using files instead. I'd prefer to accept limitations in our stream design and write a stream library that helps write the rest of our code. I don't believe we have to design a 'perfect' stream library. We can use internal details to extend the stream library. It does not appear to be hard to extend the flush_on_close to tee. Sure, a third party would not be able to do things that we can do. I think the fact that third parties are limited is OK. I've just applied the FSFS file flush changes to FSX. I think I got it right but it would have been easier with the stream approach. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
