[tahoe-dev] Another FUSE interface

[Armin Rigo]

Hi,

On Thu, Apr 24, 2008 at 08:01:12AM -0600, zooko wrote:
> > I implemented for fun another Tahoe-to-FUSE interface using my own set
> > of FUSE bindings.

> Thank you very much for the contribution!  I would like to include it  
> in Tahoe's contrib/ directory [1], but I'm not sure how much of the  
> "arigo/hack/pyfuse/" directory to include.
> 
> Or do you prefer that I include merely a link and description of  
> pyfuse instead of a copy of the pyfuse source?

For now, a link is probably more appropriate.  At some point I plan to
refactor this "hack/pyfuse/" directory into a clean library on the one
hand, and actual file systems implemented with this library on the other
hand.  If this occurs, the cleanest solution might then be to let the
tahoe file system live in Tahoe's contrib/ dir, alongside a copy of
(some version of) this library.

I'm also interested in developing this fuse interface in any direction
that makes sense.  Out of the top of my head, I would say that for my
own usage I'd consider the fuse interface to be really useful if it
contained all of this: write access (of course); "http range" reads; a
way to read the caps of files and directories and to add files and
directores by giving their caps; some correspondance between the Posix
"write" permission and the read-only-ness of caps; and a local on-disk
cache with a configurable size, which could also act as a write buffer
to avoid blocking applications during write() and close().  In fact I
suspect that not all files written to the Fuse filesystem should
automatically be uploaded (e.g. vim and emacs backup files...).  Maybe
a "check-in" model would be appropriate.


My 2 cents,

Armin Rigo