A common VFS and a Common conf-system [Part II]

[Sean Middleditch]

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
way around.

> 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.

> 
> Sincerely,
>     Rayiner Hashem
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>