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

[gtg990h at mail.gatech.edu]

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?

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

Sincerely,
    Rayiner Hashem