Julian Foad <julianfoad_at_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,
> 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*
Received on 2015-05-28 13:28:48 CEST