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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
