[tahoe-dev] notes from the LAFS Weekly Dev Chat for 2012-11-01

[Zooko Wilcox-O'Hearn]

Folks:

I apparently never posted these notes from the LAFS Weekly Dev Chat of
November 1. I'm sorry about that. I was probably planning to flesh
them out with more context and explanation, but I haven't done that,
either. So, here's a dump of my notes.

Regards,

Zooko

=== 2012-11-01 ===

#1679

* we don't have consensus on the long-term strategy for caching of
filenodes; options:
  * aggressively cache filenodes, make downloaders be indefatiguable,
so that they never cease their labors unless cancelled
  * aggressively cache filenodes, make downloaders get a fresh burst
of energy whenever a new use of the downloader is begun
  * don't cache filenodes of any kind, implement a separate
mutable-write-serializer (which looks a lot like a cache)
  * cache mutables but not immutables
* but we do have consensus on what to do right now:
  * we're going to write a unit test for the patch attached to #1679
and commit it to trunk; That means Tahoe-LAFS v1.10.0 will cache
mutables but not immutables.

#1240

* tests of corruption both before and after servermap-construction
don't apply to some parts of the data
* document which are which and why we test some of them both before
and after servermap-construction; Andrew will write, Brian will
review.

#1832

* indefinite (or long-term) but cancellable leases
* we discussed two protocols that could implement #1832:
  * the one shown on the initial description of #1832
  * one in which the client builds a manifest and delivers it to the
server in one (potentially big) message
* if I have multiple clients, they could have separate accounts
* but how to get aggregated accounting information

concurrent garbage collection

notification so you can add leases

in the leasedb schema, indefinite leases are indicated by having an
expiration time of null

encrypted timestamps

add a storage api which says "give me back something which the server
will recognize as a timestamp", and another api which says "you are
allowed to clobber everything that hasn't been created or renewed
since $THIS_TIMESTAMP"

should each lease renewal method come with an explicit
$THIS_TIMESTAMP, or should it be able to do an explicit "when you
receive this message"; the latter would unnecessarily require
limited-time-leases to do a round trip first.

we'll need separate account ids on separate leases to prevent one user
from clobbering

add a requested-duration to lease-renewal methods; if we don't have a
negotiation protocol for that, maybe make it server-side-config for
now. (#1003)