Summary: This was a brief meeting. The technical content was focused on the "Lease Database" documentation.
https://github.com/davidsarah/tahoe-lafs/blob/5161b1fb8dea9ad9dce23db5f8f7c89c3d7ea82d/docs/proposed/leasedb.rst Discussion: freddyb (having reviewed the document prior to the meetup) felt that an understanding of the "pre-leasedb" architecture was implied by the format of "leasedb.rst". warner mentioned a "Theory of Operation" (I believe this is what he was referring to: https://en.wikipedia.org/wiki/Theory_of_operation) and suggested the following format: 1) motivation 2) description of the "Steady State" operating result 3) subsequent description of edge cases (e.g. startup) Zooko suggested that the section currently titled "Motivation" should be an appendix. (I'm unclear on whether or not this is consistent with the format warner advocated.) Warner described some aspects of peer-to-peer communication in the context of Tahoe to Tom, at the edge of my hearing (i.e. I have no details to report). freddyb and I discussed the notion of a "share" he said (approximately): "Your data is divided into a set of shares a subset of which is sufficient to recover that data." [Caveat Emptor: We didn't talk about the fact that the subset is not strict, in the sense that you may need _all_ of the shares. For example, in the LeastAuthority TLOS3 case there's only 1 share. We assume decryption capability.] Our conversation was stimulated by my experience scanning the document related code in preparation for the meeting. The following assumes "immutables" as context: Before the Lease Database existed leases were stored with the data in "ShareFiles". https://github.com/tahoe-lafs/tahoe-lafs/blob/a9272522d5aff5342d08892992bf669b047c17fe/src/allmydata/storage/immutable.py#L39 These ShareFiles then provided methods both for data management (reading, writing, etc.) and for _meta_data management (renew_lease, etc.). There did not exist a class implementing an interface for a share as an object independent of the ShareFile. The accounting architecture permits the excision of the ShareFile class. Classes implementing the IShareBase, IShareForWriting, and IShareForReading interfaces replace the data management functionality, while the AccountingCrawler class handles lease data. Because the storage media is abstracted away in the cloud backend there are different types of IShareBase implementing classes: https://github.com/davidsarah/tahoe-lafs/blob/5161b1fb8dea9ad9dce23db5f8f7c89c3d7ea82d/src/allmydata/interfaces.py#L476 The AccountingCrawler is defined in the allmydata/storage directory as it uses the abstract "backend" object to interface with backends in general: https://github.com/davidsarah/tahoe-lafs/blob/5161b1fb8dea9ad9dce23db5f8f7c89c3d7ea82d/src/allmydata/storage/accounting_crawler.py#L13 In short, as reflected in the document the commonly understood concept of the "Share" is now more closely reified as a "IShareBase" than was possible in the pre-accounting architecture. We did not discuss the states of a share and the possible transitions between them. I propose those topics as the agenda for the next meetup! Changes to the content of the document as a result of the meeting are here: https://github.com/zancas/tahoe-lafs-1/blob/bc0e3766805f3f8842b6158ccf0b49d44d09ef30/docs/proposed/leasedb.rst -- -- ظ P.S.-- Dinner afterwards was great fun! _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev