[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