[tahoe-lafs-trac-stream] [tahoe-lafs] #393: mutable: implement MDMF
tahoe-lafs
trac at tahoe-lafs.org
Sat Aug 13 14:03:54 PDT 2011
#393: mutable: implement MDMF
-------------------------+-------------------------------------------------
Reporter: warner | Owner: zooko
Type: | Status: new
enhancement | Milestone: 1.9.0
Priority: major | Version: 1.0.0
Component: code- | Keywords: newcaps performance random-access
mutable | privacy gsoc mdmf mutable backward-
Resolution: | compatibility forward-compatibility review-
Launchpad Bug: | needed
-------------------------+-------------------------------------------------
Comment (by davidsarah):
A couple of possible refactorings in [5124/ticket393-MDMF-2] (these don't
need to be done for the beta):
* Rather than using pairs such as {{{(success, message)}}} or {{{(seqnum,
root_hash, IV, segsize, datalength, k, N, known_prefix, offsets_tuple)}}},
it might be clearer to use struct-like objects:
{{{
class Result(object):
def __init__(self, success=success, message=message):
self.success = success
self.message = message
def __repr__(self):
return "Result(success=%r, message=%r)" % (self.success,
self.message)
}}}
(This might be an unpleasant reminder of Java, but actually, making the
code that uses a struct less ugly and easier to read is more important
than the overhead of the struct-like class definition, IME.)
* {{{_remove_reader}}} in {{{Retrieve}}} is only called from
{{{_mark_bad_share}}}, so it could be inlined. There's a comment about
this, but it's asking about whether there might be a reason to use
{{{_remove_reader}}} independently in future. My advice would be: don't
worry about trying to predict the future, just simplify the current code
quite aggressively.
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393#comment:125>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list