[tahoe-dev] behavior of an immutable file repairer
Brian Warner
warner at lothar.com
Mon Oct 27 08:41:06 PDT 2008
Incidentally, our current IntroducerCliemt isn't designed to be used
this way (the servers= argument being a set of RemoteReferences).
Instead, you might want to pass an IClient reference in, so the
repairer can invoke get_permuted_peers(si), which will return a list
of (peerid,rref) tuples in the correct order.
(I set up the API that way in vague anticipation of a time when the
peer list was so large that we'd prefer to do the permutation on some
other host, so not everybody would have to be kept up-to-date with the
full list. Not necessarily the best way to go, mind you..)
Also, if repair=False is a possibility, then perhaps this class should
have a different name, one that doesn't imply that it always does
repair. Since the return value's type depends upon whether repair was
requested or not (CheckerResults vs CheckAndRepairResults), you might
consider using separate classes or distinct methods for the two
forms.. that's what I ended up doing for the mutable-file equivalent.
cheers,
-Brian
> def __init__(self, client, verifycap, servers, verify, repair,
> monitor):
> assert precondition(isinstance(verifycap, CHKFileVerifierURI))
> assert precondition(isinstance(servers, set))
> for (serverid, serverrref) in servers:
> assert precondition(isinstance(serverid, str))
>
More information about the tahoe-dev
mailing list