[tahoe-dev] Physical Meetup 2013-12-10: Minutes of the Meeting

Tony Arcieri tony.arcieri at gmail.com
Sat Jan 12 00:51:10 UTC 2013


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
<zancas at leastauthority.com>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 at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>



-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130111/20e3aeba/attachment.html>


More information about the tahoe-dev mailing list