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