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

[gtg990h at mail.gatech.edu]

Quoting Kevin Krammer <kevin.krammer at gmx.at>:

> I am pretty sure a file:// "plugin" isn't going to open the partitions as
> files and then implementing the filesystem access in user space.

Undoubtedly, but my point was that D-VFS should be designed so that any plugin
can be implemented using the native API. To the extent that doing so is
possible, it is desirable.

> Wouldn't that mean you had to reimplement D-VFS for every kernel you want to
> run it on?

Only if you want to use native functionality. On some OSs, the functionality
exists (eg: Linux, Windows, Darwin), and D-VFS wouldn't have to provide all
its own protocol plugins. On other OSs, like BSD, it would. Mostly, it ensures
that on the major platforms (Linux, Windows, OS X), D-VFS apps have at least
the hope of behaving like other apps. I think Mozilla should serve as an
example of how much users detest apps that don't conform.

> True, but sometimes the OS cannot be altered by the parties involved in the
> desktop projects.

That works against D-VFS on the flip-side too. If you consider Sean's
suggestions on how to integrate POSIX apps with D-VFS, it's clear that they'd
be hard to implement (eg: altering the libc) on closed-source OSs. I'd argue
that on most closed-source OSs, it is both cleaner and more "officially
supported" to write filesystem plugins than hack around the libc.

> Of course in an ideal world some standard body like POSIX would specify an
> appropriate remote access API and all OS developers would implement it the
> minute it is published, but my latest reality check says I still live in a
> non-ideal world. Bummer.

There is no need for idealism here. Just make sure that D-VFS can be
implemented on something like FUSE, or Darwin's remote file access mechanisms.
You can still have D-VFS provide its own mechanisms for OSs like BSD, but make
it possible to ditch that mechanism and integrate with the native one. Don't
count on having to usehacks like FUSE-KIO before the thing is even coded.

At least design the spec to make that possible. That means not assuming a
daemon, abstracting file names (don't assume they are URIs), taking the POSIX
hostility out of the proposal, and not being gratuitously or unnecessarily
POSIX incompatible.