Changes between Version 97 and Version 98 of GSoCIdeas2010
- Timestamp:
- 2010-03-29T01:21:16Z (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GSoCIdeas2010
v97 v98 1 Tahoe-LAFS Summer-of-Code Projects 1 = Tahoe-LAFS Summer-of-Code Projects = 2 2 3 3 This page contains specific suggestions for projects we would like to see in the Summer of Code. Note that they vary a lot in required skills and difficulty. We hope to get applications with a broad spectrum. … … 13 13 ||''Project''||''Difficulty''||''Contact''|| 14 14 ||[#RedundantArrayofIndependentClouds Redundant Array of Independent Clouds]||Medium||[mailto:zooko@zooko.com Zooko Wilcox-O'Hearn] or any mentor|| 15 ||[#RedundantArrayofIndependentClouds Redundant Array of Independent Clouds]||Medium||[mailto:zooko@zooko.com Zooko Wilcox-O'Hearn] or any mentor|| 15 16 ||[#ShareMigration Share Migration]||Medium||[mailto:warner-tahoe@lothar.com Brian Warner] or any mentor|| 16 17 ||[#SecureDecentralizedWiki Secure Decentralized Wiki]||Medium||[mailto:zooko@zooko.com Zooko Wilcox-O'Hearn] or any mentor|| … … 24 25 25 26 26 = Redundant Array of Independent Clouds = 27 == Medium-Sized Distributed Mutable Files (MDMF) == 28 29 Mutable files in Tahoe-LAFS have some significant limitations and 30 performance issues, as discussed in 31 [http://allmydata.org/trac/tahoe-lafs/browser/docs/performance.txt docs/performance.txt]. Users who aren't aware of these limitations are 32 surprised when they find out that mutable files can't scale to large 33 sizes without using unacceptable levels of memory, and that reading one 34 byte of the file costs as much as reading the entire file. 35 36 A fix for this issue would essentially be fixing #393. That is, 37 38 * Developing mutable files that are segmented on upload, as with immutable files. Part of this would involve making sure that the way we currently ensure the integrity of the parts of mutable files stored on servers is adequate for your new design, and altering it if it isn't. 39 * Implementing efficient reading and writing of arbitrary spans of those mutable files. 40 41 This would make Tahoe-LAFS less surprising to users, and allow mutable 42 files to be used in more ways than they currently are. If successful enough, this might allow Tahoe-LAFS to support range queries or "graph database"-style access, in the style of the "NoSQL" projects. 43 44 To learn more about this issue, you should first read 45 [http://allmydata.org/trac/tahoe-lafs/browser/docs/performance.txt docs/performance.txt], so you're familiar with the performance problems 46 with mutable files as currently implemented. You should also look at the 47 [http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.txt file encoding specification], to understand how immutable files are 48 segmented (since you'll be doing something similar with this project). [http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/mutable.txt The mutable file specification] may be informative as well. 49 The mutable file upload and download code is in 50 [http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/mutable mutable], 51 and, for comparison, the immutable file upload and download code is in 52 [http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/immutable immutable]. 53 54 == Redundant Array of Independent Clouds == 27 55 28 56 Add backends to the storage servers so that they store their shares on a cloud storage system instead of on their local filesystem. This means that you can get all of the availability and scalability of services such as Amazon S3 or Rackspace !CloudFiles combined with the security properties of Tahoe-LAFS. See [http://allmydata.org/~zooko/RAIC.png the RAIC diagram]. For details read ticket #999 which including pointers to the relevant source code and instructions on how to begin writing the code. 29 57 30 = Share Migration=58 == Share Migration == 31 59 32 60 When uploading a file to a grid, Tahoe-LAFS will make sure that the file is … … 65 93 jumping-off point for health is #778. 66 94 67 = Secure Decentralized Wiki=95 == Secure Decentralized Wiki == 68 96 69 97 Write a wiki in Google's [http://code.google.com/p/google-caja/ "caja"] dialect of !JavaScript. This wiki will load and store data directly on a Tahoe-LAFS storage grid so that it is a full "Cloud App"—there is no server. All computation is done in the user's web browser in caja and all of the storage is done by the decentralized Tahoe-LAFS storage grid. This wiki should leverage Tahoe-LAFS's secure sharing features to offer fine-grained, dynamic, and easy transclusion or client-side mashups. This project is intended to be the successor to [http://allmydata.org/trac/tiddly_on_tahoe the TiddlyWiki-on-Tahoe-LAFS project], which is a wiki written in !JavaScript and hosted on Tahoe-LAFS, but one that has been "bolted on" to Tahoe-LAFS instead of designed for Tahoe-LAFS, and is currently incapable of good transclusions or mashups. … … 71 99 To get started, play with [http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:7h7syiurogz5erc2au74tjwguu:h7bdxvjtvidlkcdbld3j2d5sbgyzsbqs7wdnu6yznqrejzssc5za/wiki.html the TiddlyWiki-on-Tahoe-LAFS quick start], read the source code of [http://allmydata.org/trac/tiddly_on_tahoe/browser/tahoe_tiddly/HTTPSavingPlugin.js the HTTPSavingPlugin] and [http://allmydata.org/trac/tiddly_on_tahoe/browser/tahoe_tiddly/TahoePlugin.js the TahoePlugin] for !TiddlyWiki, and experiment with [http://caja.appspot.com/ writing live caja applets]. 72 100 73 = Cloud Apps=101 == Cloud Apps == 74 102 75 103 Difficulty: easy to hard, depending on project choice and how far you want to push it … … 77 105 Invent your own Summer-of-Code project by building a new web app on top of Tahoe-LAFS. The [#SecureDecentralizedWiki Secure Decentralized Wiki] is one example of a Cloud App. See [wiki:GSoCIdeas/CloudApps] for other ideas. 78 106 79 = WebDAV Support=107 == WebDAV Support == 80 108 81 109 Difficulty: medium to hard, depending on how much of an existing WebDAV implementation you are able to reuse … … 128 156 [http://allmydata.org/trac/tahoe-lafs/query?status=!closed&order=priority&keywords=~webdav Tickets labelled 'webdav'] 129 157 130 131 = Distributed Introduction = 158 == Distributed Introduction == 132 159 133 160 Implement a protocol for distributed introduction, thus removing the only remaining Single Point of Failure (SPoF) in the Tahoe-LAFS system. For details see [comment:11:ticket:68 ticket #68] which describes the distributed notification algorithm and points to the relevant source code. 134 161 135 = DVCS Integration=162 == DVCS Integration == 136 163 137 164 Write patches for the [http://git-scm.com/ git] or [http://darcs.net darcs] distributed revision control tool so that it reads and writes directly to a Tahoe-LAFS storage grid instead of its local filesystem. This creates a "revision control repository in the sky"—a repository that is distributed, fault-tolerant, and highly available. It also lends Tahoe-LAFS's unique security and access-control properties to your revision control system—you can share read-only access or read-write access with specific people through Tahoe-LAFS's capability access control system, and you can rely on the integrated digital signatures to verify that you are reading an authorized version of the repository.