[tahoe-dev] Accounting, 2010 edition
David-Sarah Hopwood
david-sarah at jacaranda.org
Tue Dec 21 03:09:39 UTC 2010
On 2010-12-21 03:01, David-Sarah Hopwood wrote:
> On 2010-12-20 22:16, Brian Warner wrote:
>> The two additional APIs we've thought about are batch-renew and
>> batch-cancel-everything-else methods. The batch-renew is what you'd use
>> after you've done a deep-traversal of your directory tree (i.e. "tahoe
>> manifest"), and then you (or somebody you've paid to renew your shares
>> while you're on vacation) renew all of them in a single call. We could
>> use Bloom Filters here to reduce the amount of data transmitted, since
>> adding leases to a few extra files won't hurt too much.
>>
>> The other API would be used in a similar way, right after you build a
>> manifest, but it would mean "immediately cancel all my leases on shares
>> that weren't in the manifest". This would even be safe if only you could
>> lock your directory tree against changes, build a manifest, issue the
>> batch-cancel, then finally unlock the tree. Otherwise you might be
>> telling the server to cancel something that you actually care about (but
>> started caring about too late for it to be included in the manifest).
>
> Make the cancel operation a long-running operation (using an ophandle).
Actually it would be a foolscap reference rather than an ophandle, since
this operation would be part of the storage server protocol, presumably?
> Then it can cancel all shares that were present before the operation
> started and that are not in the manifest.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101221/5a054bd9/attachment.pgp>
More information about the tahoe-dev
mailing list