From 15d4c86db3b9e7b25dcd706c9d03d2592ab1c010 Mon Sep 17 00:00:00 2001
From: arch_o_median <>
Date: Thu, 12 Mar 2009 20:30:44 +0000
Subject: [PATCH] [Imported from Trac: page GSoCIdeas2010, version 12]
---
GSoCIdeas2010.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/GSoCIdeas2010.md b/GSoCIdeas2010.md
index d8b775c..99b7432 100644
--- a/GSoCIdeas2010.md
+++ b/GSoCIdeas2010.md
@@ -6,8 +6,8 @@ What could a smart student do in one summer, if they didn't need to worry about
* 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
* 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 (). 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 pratical 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 have many machines and alternate 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 keep showing me the same first level directories in any level :)
+ * 'tahoe sync'. The proposed #601 bidirectional sync option would be great for using tahoe as we would with dropbox (). 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)
* Make the [Windows client](http://allmydata.org/trac/tahoe-w32-client) use only free open-source software