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

[gtg990h at mail.gatech.edu]

Quoting Sean Middleditch <elanthis at awesomeplay.com>:

> > > It's the only answer feasible.  What other answer is there?  There's no
> > > other possible solution except FUSE, which is Linux-only, which means
> > > that it is completely unsuitable for our purposes.  If an application
> > > wants to use D-VFS, nothing stops it from doing so except apathy or
> > > ignorance.
> >
> > Apathy, ignorance, and inertia. Don't underestimate the power of the
> triumvirate
> > However, saying to the user "sorry the interface sucks, but the gcc folks
> are
> > ignorant" is not constructive.
>
> I never said they were.

The implication of 'nothing stops it from doing so except apathy or ignorance'
is that if the GCC folks never use D-VFS (likely), they must be apathetic or
ignorant. That's just not true. There is an enormous class of apps that find
POSIX to be a perfectly good API. Adopting the D-VFS API should not be a
prerequisite for accessing remote filesystems through D-VFS.

There are two requirements here: remote file access, and a higher level API.
Tying the two together means that apps that don't feel the need for a
higher-level API won't give users transparent file access either.

> > With regards to solutions, one be to seperate D-VFS into a front-end and a
> > backend. Design the frontend so it can be implemented on a purely POSIX
> API.
>
> So you're arguing now for what is already written in the wiki, what I've
> already stated several times about making D-VFS usable as a FUSE
> backend, etc?

I'm arguing that it should be possible to use FUSE as a D-VFS backend, not the
other way around. That's an important difference, because the latter still
results in two namespaces. I'm arguing that instead of trying to provide its own
mechanisms, D-VFS should try to use OS-native mechanisms when possible, and only
fall-back to its own backend when necessary. On the majority of systems (MacOS
X, Windows, Linux), the D-VFS implementation of sshfs, etc, should not be
necessary.

What I'm worried about is that D-VFS will be designed like KIO or gnome-vfs, and
properly integrating it with native functionality is going to require a hack
like FUSE-KIO. It seems silly to me to plan on a hack for a piece of software
that doesn't even exist yet.

> No, file handling will be the same.  Modern apps should prefer the far
> more expressive and easy to use D-VFS API (POSIX really does suck in
> many different ways) and legacy apps would need a mounted file system.

No, it wouldn't. When using "modern" apps, users would have to use
protocol://file URIs, while using "legacy" apps would use something like
/mnt/protocol/file paths. Not to mention that users would have to deal with
mounting FUSE shares themselves, etc. What D-VFS should do on Linux/Windows/OS X
is to provide an intelligent mechanism for handling the mounting, and let native
mechanisms take care of the rest. As a fallback, it could offer it's own
mechanisms for those OSs that don't have their own.

Beyond that, I have a bad feeling about a project that wants to muck with
something as basic as the UNIX file API, and then declare every UNIX application
in existance to be "legacy". That's making a decision that has huge
ramifications on the design of the system as a whole, and is not something to be
considered lightly. Is D-VFS just a desktop filesystem API, or is its goal to
replace POSIX for all "modern" apps? You can't hedge and say "it's just for
desktop apps, but since POSIX sucks, everything else should be ported to it
too".

> No, it's the job of people who care about the bridge.  I am not stopping
> FUSE developers from making a D-VFS handler.  I'm not going to do it for
> them, and I won't compromise the design of D-VFS just to make it a
> little easier for them.  POSIX sucks, the entire *reason* to write D-VFS
> instead of just porting FUSE to BSD and Solaris and such is to provide a
> simpler, more expressive, less error prone API than POSIX that has the
> additional immense benefit of handling remote shares transparently.

I thought the reason for D-VFS was to have a cross-desktop replacement for
gnome-vfs and KIO. What is D-VFS exactly? Is it an easier to use API? Because
that can be done on top of native APIs, ala efsd. Is it a remote filesystem
layer? Because that can (and has) be done in the context of native APIs. The two
are orthogonal, and the weakness of D-VFS as a concept is that it unnecessarily
ties the two together.