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) _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE