| Version 16 (modified by zooko, at 2013-04-23T20:57:53Z) (diff) |
|---|
See also GSoCIdeas2010 and GSoCIdeas2009
Hey prospective GSoC students! You want us, the mentors of the Tahoe-LAFS project, to choose to sponsor your GSoC project instead of some other student's project, right? Well, here's how to rocket to the top of our list in three easy steps:
- Browse through the "Suggested Summer-of-Code Projects" list below.
- Then, explore our issue tracker, Roadmap, and mailing list archive and find a *different* project that you're interested in, that is not on the list below.
- Then, join irc.freenode.net channel #Tahoe-LAFS, or attend our WeeklyMeeting and talk over the idea of working on that *different* project for GSoC 2013.
You might end up working on one of the projects below even after going through this process. But any student who seriously digs into their own project idea, as outlined in the three steps above, will be preferred over a student who merely applies to do one of the projects below.
Tahoe-LAFS Suggested Summer-of-Code Projects
| Project | Tickets | Difficulty |
| Share rebalancing and repair | #699, #232 | tricky |
| Make It Go Faster | #327, #932, #1406, #1530 ; wiki:Performance | complex |
| Upload Strategy Of Happiness | #610, #1124, #1130, #1293, #1382, #1814 | subtle |
| Advanced Cap Types | #795, #796, #954, #958 | inconceivable |
Share Rebalancing and Repair
Tahoe-LAFS is not as robust with regards to lost or corrupted shares as it could be. In part, this is because the repair functionality is limited in its efforts to spread shares out among new servers or servers which did not previously hold a given share (#699). In addition, mutable files do not spread out to new servers upon modification (#232).
A Summer of Code project might tackle repair and rebalancing, ensuring that servers-of-happiness is met whenever possible on any upload, repair, or mutable modification. The notes on ServerSelection and related configurations may also be relevant here.
Make It Go Faster
Tahoe-LAFS is very slow at downloading files. Potential users have been looking at this and then deciding not to use Tahoe-LAFS because they need better performance. Figure out why and make it go faster. The first step of this project is to make an automated robot that measures performance of download. The next step is to inspect the pretty, interactive, javascript-powered "download visualization" and figure out what is making the downloads take so long. Then try to improve that thing, see if the automated performance measurements and the visualization show that your improvement worked, and iterate. #327, #932, #1406, #1530 ; wiki:Performance
Upload Strategy Of Happiness
The Servers of Happiness criterion is already in place for deciding, after a distribution of shares to servers has been chosen, whether that distribution satisfies the user's requirements for fault-tolerance. However, the algorithm that decides what shares to upload to which servers is not optimized to always satisfy the Servers of Happiness criterion. Kevan Carstensen's master's thesis explains the context in great details and proposes an Upload Strategy of Happiness algorithm for allocating shares to servers. Implementing the Upload Strategy of Happiness should close the following tickets: #610, #1124, #1130, #1293, #1382, #1814.
Advanced Cap Types
The current set of cap types is described on wiki:Capabilities. There are several proposals for extended semantics: revocable write-caps (#954), a secure "301 Moved Permanently" redirect (#958), add-only sets (#795), write-only caps (#796).
