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

[gtg990h at mail.gatech.edu]

Quoting Sean Middleditch <elanthis at awesomeplay.com>:

> If you mean using something like the /remote/http/server/path setup
> with /remote being a special folder to indicate using access a remote
> share, that is not acceptable because you *still* have two namespaces -
> the difference between a real, portable, standard URI and some custom
> proprietary (yes, that's the right word for it) D-VFS scheme.

Um, how is /remote/http/server/path proprietory? That's how UNIX path names
work. Ideally, of course, it wouldn't be /remote/http/server/path, but whatever
format the OS used natively. On UNIX, that's what it would be.

> A URI is the right way to specify a file.  That's what a URI is designed
> for.  Having applications do something like open("http://server/path")
> is how one should open a file.

On no existing OS is a URI the "right way" to specify the file. The "right way"
is whatever the rest of the OS uses. If you're designing a new OS, you can make
it use URIs, but D-VFS isn't a new OS. It's just a part of a desktop app
framework, and those are in no position to dictate OS-level paradigms to
existing OSs.

Of course, naming is not even close to being the point. My problem isn't the
naming scheme --- it's the creation of an alternate namespace that existing apps
cannot access using existing mechanisms.

> If someone wants to hack the Linux kernel or glibc to make the normal
> POSIX API recognize a URI and get it to communicate with a VFS daemon,
> and manages to do it in a spec-compliant way that doesn't break a lot of
> apps, that would be *wonderful*.

What is the goal here? Is D-VFS a convenience API for desktop apps, or the "One
True Model" of how filesystem access should be done? If it's the former, it
should integrate with the native system, not force the native system to adapt to
it. Especially considering that on OS X and Windows doing this wouldn't even be
possible.

> Anyone is free to make a system that uses D-VFS to accomplish that goal,
> and I'd welcome such a project, and I guarantee you I'd gladly make
> frequent use of it.  But trying to design D-VFS around such a system is
> just going to limit development in unnecessary ways.

The goal isn't to use D-VFS to accomplish that goal, but rather to ensure that
D-VFS's design doesn't hinder that goal. The fact that FUSE-KIO exists shows
that there is a need for interoperation between VFS and "legacy" apps. Such
interoperation will have to happen. Now, it can either happen via hacks, like
FUSE-KIO, or be cleanly integrated into the system. I don't see the rationale
for planning for hacks in a system that doesn't even exist yet.

> Because, like I said, it's a problem solvable outside D-VFS, using FUSE
> or something like it, and that's not related to D-VFS development at
> all.  It's a different problem space.

The minute D-VFS decided to get involved in namespace issues, it became D-VFS's
problem. Namespace issues affect the whole system. Saying "D-VFS is just a
desktop filesystem layer" doesn't change that. At the end of the day, the user
won't care about the excuses, he'll just see that different apps see the
filesystem in different ways.

> Here's the rub - either you hack the kernel/libc, or you port the
> application.  That's it.

Or, you build D-VFS so it can take advantage of the OS's native remote access
APIs! Give up on trying to replace what already exists, and just provide a
cross-platform, convenient way of accessing it (auto-mounting for stuff like
FUSE, etc), providing fallback functionality if necessary. What is wrong with
that solution? Is it harder? Probably. But it's far better from the perspective
of the user, and has the decided advantage of not having to declare all existing
software "legacy".

> it's a cross-platform API.  That means a *new* API.

Just because it is a new API doesn't mean that it cannot be built on existing
ones. Efsd offers an API with features similar to those proposed for D-VFS.
Clearly, D-VFS's functionality can be built upon POSIX (and indeed, must be,
because a file:// protocol has to exist). I haven't seen a good argument for why
this isn't possible, and some people have made arguments for why it is.

>  If you want to wrap
> POSIX around it, as I've said more times than I care to count now,
> GREAT!  PLEASE DO!  USE D-VFS!  But that goal does not preclude D-VFS
> from offering a new, better API, and it does not require that D-VFS do
> anything particularly special other than what is already planned.

Unless you're proposing that Linux (or Windows) become a microkernel and D-VFS
become the FS server, wrapping POSIX over D-VFS is not an option. Your position
is internally inconsistent. You say that D-VFS is just a desktop filesystem
layer, but then say that, to achieve a decent user experience, all apps need to
be ported to use it (or hacked to use it, via LD_PRELOAD hacks).

>
> This discussion has gone in a circle twice now.  The solution you want
> needs to happen outside of D-VFS, but is completely compatible with
> D-VFS.

The discussion is going in a circle because you are unable to see that the
proposal for D-VFS is *not* compatible with such a solution. You're not
disagreeing with me that having two namespaces is less than ideal, you just have
a different idea bout D-VFS's place in the system as a whole.

If you want to end this discussion, fine, it's your software and you can do what
you want with it. However, to the extent that desktops might actually adopt the
D-VFS API, at least make D-VFS a proper spec first. That means removing wording
like "the daemon will be a required part of the implementation", leaving that up
to implementation details. It should not be impossible to implement D-VFS apps
in a way so that they actually behave like native apps if desired.
----- End forwarded message -----


--