A common VFS and a Common conf-system [Part II]
elanthis at awesomeplay.com
Tue Mar 8 06:19:22 EET 2005
On Mon, 2005-03-07 at 21:32 -0500, gtg990h at mail.gatech.edu wrote:
> I've been reading with some excitement the D-VFS proposals being thrown around
> on xdg. One thing that seems to have been taken for granted is: is it really a
> good idea to have a seperate filesystem interface just for desktop apps? While
> the proposal on http://www.freedesktop.org/wiki/Software_2fdvfs mentions a
> number of excellent points about the needs of desktop apps, those points don't
> necessarily argue for creating a parallel mechanism for file access.
> The biggest thing about D-VFS, which I think has not been considered
> sufficiently, is that it introduces a new, overlapping namespace for files. That
> makes D-VFS more than just a "desktop thing"; namespace design influences the
> whole system.
> It's clear that apps like GCC or MAKE will never use D-VFS. Now, what happens in
> an IDE? Say the user navigates to a directory on an SSH share, and tries to
> build the project. What does the app do? Copy the whole share to a local
> directory to do the build? Prevent the user from starting the build on a remote
> share? Are either of these in any way clean solutions?
They can patch GCC if they don't like any of those solutions. Nothing
about D-VFS will make it impossible for non-desktop apps to use. It's
just not something that a whole ton of time is being devoted to.
> With FUSE potentially going into the kernel, I'd argue that any D-VFS proposal
> has to take it into account. FUSE already provides the mechanisms to what the
When FUSE equivalents are in BSD, Solaris, HP-UX, Cygwin, Irix, etc.,
*then* it's worth taking into consideration. Until then, FUSE is
absolutely useless to D-VFS, unless we code some huge and massively
different version just for Linux, which is both insane and pointless.
If FUSE wants to use D-VFS, great, but it should *not* work the other
> D-VFS fundementally aims to --- provide access to filesystems in userspace.
> Other considerations, such as notification or easy-to-use APIs, could be handled
> via a seperate daemon, without resorting to fragmenting the file namespace. I
> think such solutions should be considered.
Unfortunately, the "namespace" is already fragmented. Many apps already
have their own built-in VFS systems, users are accoustomed to using many
custom apps to access different kinds of remote shares, GNOME and KDE
already have their VFS systems, etc. D-VFS entire goal is to actually
*unify* the VFS landscape by getting rid of the need to have a bazillion
separate systems that all do essentially the same thing. If non-desktop
apps really want to get in on the fun, they're free to. I honestly do
think that it would be best if POSIX/UNIX in general had a standard
"remote share access" API that didn't need mounting. That's not likely
to happen anytime soon, though, thus D-VFS.
> Rayiner Hashem
> xdg mailing list
> xdg at lists.freedesktop.org
Sean Middleditch <elanthis at awesomeplay.com>
More information about the xdg