[tahoe-dev] Physical Meetup 2013-12-10: Minutes of the Meeting
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
Re: [tahoe-dev] Physical Meetup 2013-12-10: Minutes of the Meeting
Sorry I missed this, and seeing Zooko in town. Next time! ;) Also I'd love to get my UI patch up for review at the next in-person meetup and if it's on the schedule I can confirm I will show up On Fri, Jan 11, 2013 at 4:31 PM, Zancas Dearana wrote: > 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 > -- Tony Arcieri ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: [tahoe-dev] Physical Meetup 2013-12-10: Minutes of the Meeting
Oops, just realized next Thursday is the Github meetup. Week after that? ;) On Fri, Jan 11, 2013 at 4:51 PM, Tony Arcieri wrote: > Sorry I missed this, and seeing Zooko in town. Next time! ;) > > Also I'd love to get my UI patch up for review at the next in-person > meetup and if it's on the schedule I can confirm I will show up > > > On Fri, Jan 11, 2013 at 4:31 PM, Zancas Dearana > wrote: > >> 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 >> > > > > -- > Tony Arcieri > -- Tony Arcieri ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev