[tahoe-dev] [tahoe-lafs] #607: DIR2:CHK
tahoe-lafs
trac at allmydata.org
Mon Aug 31 20:34:39 PDT 2009
#607: DIR2:CHK
---------------------------+------------------------------------------------
Reporter: zooko | Owner:
Type: defect | Status: new
Priority: major | Milestone: undecided
Component: code-dirnodes | Version: 1.2.0
Keywords: | Launchpad_bug:
---------------------------+------------------------------------------------
Comment(by warner):
Zooko and I had a chat, and agreed to leave the encoding format the same.
So
"DIR2:" and "DIR2-CHK" (or -IMM or something) will have the same format,
just
in different containers. We can put off a format change until DIR3.
We're not sure about the "prototype immutable filenode" refactoring (the
one
that would make dirnodes call the same write() method for both mutable and
immutable filenodes). It might be better off deferred.
One way to make the download/read side more uniform would be to introduce
"!FileVersion" objects. I might have described these in some other ticket,
but the idea would be to move the read/write methods out of
!MutableFileNode
and onto this !FileVersion object which represents a single specific
version
of the mutable slot. {{{FileVersion.replace}}} would encapsulate the
servermap argument, performing the replacement only if the mutable file
looked like it hadn't changed since the version was fetched.
{{{MutableFileNode.get_best_version()}}} would return one of these version
objects. {{{ImmutableFileNode.get_best_version()}}} would return self.
Then
we'd make sure the read() interface was the same for both. (this would
dovetail nicely with the future LDMF files, which will offer multiple
versions: once you've grabbed the one that you care about, use read() on
it).
This would take a moderate amount of work, but would allow us to use the
same
dirnode code for both types: the dirnode read code would just do
{{{self._filenode.get_best_version().read()}}}.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/607#comment:3>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list