archive today's agenda, post next week's
[Imported from Trac: page WeeklyMeeting, version 29]
parent
e8e19ca720
commit
8bc828574d
|
@ -23,30 +23,30 @@ There is a weekly conference call using [Google Hangout](https://www.google.com/
|
||||||
|
|
||||||
## Agenda
|
## Agenda
|
||||||
|
|
||||||
URL: <https://plus.google.com/hangouts/_/748b6f70b1845e6bbede00fd399a7ce7f8ef3a7f>
|
URL:
|
||||||
|
|
||||||
Upcoming: 2012-11-15
|
Upcoming: 2012-11-22
|
||||||
|
|
||||||
This will be a *TESLA COILS AND CORPSES* meeting: science, big new features, writing papers about our work, etc. If you're more into *NUTS AND BOLTS* then stay tuned for a future meeting about engineering, debugging, making stable releases, etc.
|
This will be a *TESLA COILS AND CORPSES* meeting: science, big new features, writing papers about our work, etc. If you're more into *NUTS AND BOLTS* then stay tuned for a future meeting about engineering, debugging, making stable releases, etc.
|
||||||
|
|
||||||
Agenda: async notifications
|
Agenda: Proof-of-Retrievability
|
||||||
|
|
||||||
What a *lot* of people really want is an alternative to Dropbox — something that functions very like Dropbox but without exposing your plaintext to spying and corruption. David-Sarah implemented a part of this with the drop-upload feature. It seems to me that the blocker which prevents Tahoe-LAFS from doing the rest of it is that LAFS clients have no way to get an asynchronous notification that a file has changed (i.e., so that they don't have to poll to find out if the file has changed). So: could we add that? Why not just define a remote interface offered by LAFS clients to LAFS servers. The remove interface is "hey_you_this_file_has_changed(storageindex)".
|
|
||||||
|
|
||||||
Another approach would be to embrace a standard mechanism like PubSubHubBub. That might help with our long-term goal of moving from foolscap to HTTP, and it might let us benefit from the work others do on issues around this such as DoS and scalability.
|
|
||||||
|
|
||||||
## Proposed Future Topics
|
## Proposed Future Topics
|
||||||
|
|
||||||
* **Tahoe-LAFS v1.10** What can we do to move Tahoe-LAFS v1.10 along? Is David-Sarah too busy with LeastAuthority.com to be Release Manager for Tahoe-LAFS v1.10? Should Tahoe-LAFS v1.10 contain only patches that are already on trunk?
|
* **Tahoe-LAFS v1.10** What can we do to move Tahoe-LAFS v1.10 along? Is David-Sarah too busy with LeastAuthority.com to be Release Manager for Tahoe-LAFS v1.10? Should Tahoe-LAFS v1.10 contain only patches that are already on trunk?
|
||||||
|
|
||||||
* **Proof-of-Retrievability** review of a paper draft Zooko will distribute. (was scheduled: ~~2012-10-30~~)
|
|
||||||
|
|
||||||
* **Rainhill design review** which David-Sarah will distribute; call for outside crypto expert reviewers. (was scheduled: ~~2012-11-06~~)
|
* **Rainhill design review** which David-Sarah will distribute; call for outside crypto expert reviewers. (was scheduled: ~~2012-11-06~~)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Notes / Archives
|
## Notes / Archives
|
||||||
|
|
||||||
|
### 2012-11-15
|
||||||
|
|
||||||
|
* async notifications
|
||||||
|
|
||||||
|
What a *lot* of people really want is an alternative to Dropbox — something that functions very like Dropbox but without exposing your plaintext to spying and corruption. David-Sarah implemented a part of this with the drop-upload feature. It seems to me that the blocker which prevents Tahoe-LAFS from doing the rest of it is that LAFS clients have no way to get an asynchronous notification that a file has changed (i.e., so that they don't have to poll to find out if the file has changed). So: could we add that? Why not just define a remote interface offered by LAFS clients to LAFS servers. The remove interface is "hey_you_this_file_has_changed(storageindex)".
|
||||||
|
|
||||||
### 2012-11-08
|
### 2012-11-08
|
||||||
|
|
||||||
* #1240; Is it done? (I think it still needs fixed tests.) Can we commit it to trunk and be done with it? Do we need to merge it with #1679?
|
* #1240; Is it done? (I think it still needs fixed tests.) Can we commit it to trunk and be done with it? Do we need to merge it with #1679?
|
||||||
|
|
Loading…
Reference in a new issue