edity edit

[Imported from Trac: page GSoCIdeas2010, version 23]
zooko 2009-03-17 01:57:47 +00:00
parent 10efbccd63
commit dbbb090098

@ -5,14 +5,15 @@ What could a smart student do in one summer, if they didn't need to worry about
* Dynamic share migration to maintain file health * Dynamic share migration to maintain file health
* use Zeroconf or similar so nodes can find each other on a local network to enable quick local share migration * use Zeroconf or similar so nodes can find each other on a local network to enable quick local share migration
* Deal with unreliable nodes and connections in general, getting away from allmydata's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction * Deal with unreliable nodes and connections in general, getting away from allmydata's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction
* Shell friendly errors. When cli (the shell command tool) is failing, it would be good, for shell users, to have a nicer output in text format, not html/css. The latter could be kept for webgui errors only.
* 'tahoe sync'. The proposed #601 bidirectional sync option would be great for using tahoe as we would with dropbox (<http://www.getdropbox.com/>). Like the latter, the user could have a daemon which keeps things in sync in pollings within a one or two seconds schedule (maybe using inotify for uploads). In practical terms an user could have many machines pointing to the same tahoe:dir, each machine mapping this resource to a local directory, and all these machines could then have their local copies in sync, via tahoe:dir. I think this is good when someone has many machines and alternates use between them, like a notebook, a home desktop and an office desktop, for instance. * 'tahoe sync'. The proposed #601 bidirectional sync option would be great for using tahoe as we would with dropbox (<http://www.getdropbox.com/>). Like the latter, the user could have a daemon which keeps things in sync in pollings within a one or two seconds schedule (maybe using inotify for uploads). In practical terms an user could have many machines pointing to the same tahoe:dir, each machine mapping this resource to a local directory, and all these machines could then have their local copies in sync, via tahoe:dir. I think this is good when someone has many machines and alternates use between them, like a notebook, a home desktop and an office desktop, for instance.
* sshfs working properly in linux boxes. Yeah, my Fedora 9 isn't ok with trunk revision, it keeps showing me the same first level directories in any level :)
* Help with the C client library [libtahoeclient_webapi](http://allmydata.org/trac/libtahoeclient_webapi) * Help with the C client library [libtahoeclient_webapi](http://allmydata.org/trac/libtahoeclient_webapi)
* Make the [Windows client](http://allmydata.org/trac/tahoe-w32-client) use only free open-source software * Make the [Windows client](http://allmydata.org/trac/tahoe-w32-client) use only free open-source software
* Various web frontend applications: * Various web frontend applications:
* An interactive tree browser web frontend. * An interactive tree browser web frontend.
* A blog-like app (perhaps addressing tiddly wishlist items) * A blog-like app (perhaps addressing tiddly wishlist items)
* *Or*, extend and improve the `tiddly_on_tahoe` implementation
* *Or*, retarget the [TiddlyWeb](http://tiddlywiki.org/wiki/TiddlyWeb) to use Tahoe as its backend storage?
* Port another light-weight server open source web app to Tahoe+javascript (calendar, photo album, [Bespin](https://bespin.mozilla.com)) * Port another light-weight server open source web app to Tahoe+javascript (calendar, photo album, [Bespin](https://bespin.mozilla.com))
* Fix Same-Origin-Policy design issue. Web content from different authors can interact in unintended ways in the victims browser, such as Javascript iterating over open windows, or peeking at a referrer header. Before this project is undertaken, the problem description and proposed solutions need careful design review and consideration! The solutions should be considered prototypes and should be backwards compatible with the Tahoe network. * Fix Same-Origin-Policy design issue. Web content from different authors can interact in unintended ways in the victims browser, such as Javascript iterating over open windows, or peeking at a referrer header. Before this project is undertaken, the problem description and proposed solutions need careful design review and consideration! The solutions should be considered prototypes and should be backwards compatible with the Tahoe network.
* Domain Mangling approaches: * Domain Mangling approaches:
@ -28,4 +29,10 @@ Who is willing to spend about five hours a week (according to Google) helping a
* Brian Warner (core coding, Python/Twisted/Foolscap) * Brian Warner (core coding, Python/Twisted/Foolscap)
* [Zooko O'Whielacronx](http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html) (core coding, Python/C/C++/JavaScript, cryptography) * [Zooko O'Whielacronx](http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html) (core coding, Python/C/C++/JavaScript, cryptography)
* [Jack Lloyd](http://www.randombit.net) (C/C++/Python, cryptography) * [Jack Lloyd](http://www.randombit.net) (C/C++/Python, cryptography)
* Nathan Wilcox (frontends Python/JavaScript/C/C++, security) * Nathan Wilcox (frontends Python/JavaScript/C/C++, security)
# Tasks Too Small To Be A Whole Project Unto Themselves
But they could perhaps be the starting point of a summer project -- i.e. get into the code by fixing this bug and then build a solid addition to this part of the system.
* sshfs working properly in linux boxes. Yeah, my Fedora 9 isn't ok with trunk revision, it keeps showing me the same first level directories in any level :)