[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