[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1680819 - /subversion/trunk/subversion/libsvn_fs_fs/revprops.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 28 May 2015 12:28:33 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.