subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <>
Subject Re: svn commit: r1680819 - /subversion/trunk/subversion/libsvn_fs_fs/revprops.c
Date Thu, 28 May 2015 11:28:33 GMT
Julian Foad <> 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*

View raw message