- From: Florian Festi <ffesti redhat com>
- To: gnome-vfs-list gnome org
- Subject: gnome-vfs replacement
- Date: Tue, 10 Oct 2006 15:34:02 +0200
I've originally been looking at FUSE and at different backends including
the gvfs2 backend. While trying to fix the gvfs2 backend I stumbled
across your discussion about the reimplementation of gvfs.
I'd like to offer my help although I probably have a very different view
to the problem.
I strongly disagree with the idea of not supporting the whole POSIX file
API at the backends. Critical point seams to be seek(). I understand
that not all backends can support that (as not all files support it).
But completely dropping that function will make integration of FUSE
impossible (Which I am most interested in). May be there is a way of
either offer a way to ask what operations a file(info) does support or
(like POSIX) just issue an error.
If we even want to support some kind of mounting/unmounting I think it
is not a good idea to exclude FUSE just from the beginning.
I personally have the vision that (if FUSE is enabled) all backends that
support FUSE (= full POSIX file interface) are really mounted into the
file system and offered the applications as native files. (OK, this has
already discussed here). Other backends are only "mounted" into the file
system virtually. This means for GNOME apps they are just like normaly
files if they use the gvfs3 lib, but others won't have a chance to
As the whole thing is going to get a bit tricky it might be an idea to
implement a prototype first - may be in a language that requires less
wizardry to support OO like constructs than C.
] [Thread Prev