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

[gtg990h at mail.gatech.edu]

Quoting Nicolai Haehnle <prefect_ at gmx.net>:

> Besides, the namespace confusion can be eased by providing conversion
> functions in the D-VFS library.

Easier for whom? The developer? Maybe. But the user still has to deal with the
fact that his or her "desktop" apps and "non-desktop apps" (whatever that
distinction entails --- apparently, it's not as simple as "gui" vs "non-gui")
deal with files in a different way.

> Even if all the problems related to password prompts were dealt with, how
> would you e.g. deal with mimetype or cookies sent by an HTTP server?

I'm curious to see what needs D-VFS has that could not be satisfied by extended
attributes. Certainly, people use davfs quite happily on OS X without more than
that. Even if the interface does need extending, there is good reason to extend
it rather than ditch it entirely for a new one.

In Linux, anyway, there is ongoing work to deal with the metadata issue, because
of Reiser4 (among other things). Say a year down the road, Linux has APIs for
this. Will D-VFS be unable to use them? That's the real impetus for making D-VFS
operate on top of the native filesystem. As the OS becomes more capable, D-VFS
can shunt more work to it.

> In a backend<->FUSE<->kernel<->D-VFS scenario,

The organization would go more like: D-VFS -> kernel -> FUSE. There is little to
no abstraction loss between the kernel and FUSE, because the FUSE VFS *is* the
kernel VFS. There need not be any loss between the kernel VFS and D-VFS, because
D-VFS doesn't exist yet, and can be designed in a way such that this loss does
not happen.

> abstraction going on that we will invariably lose information, and whenever
> the need arises to extended the D-VFS API with useful functionality in the
> future, all those three interfaces might have to be changed instead of just
> a single backend<->D-VFS interface.

The question here is that is ease of coding a good excuse for doing something
fundementally wrong from a user perspective? An easy solution is useless if it's
the wrong solution. Nobody has offered a convincing argument for why fragmenting
the namespace is the "right solution". The fact that it's the easier solution is
secondary.

> It's simply unrealistic to expect all operating systems that open-source
> desktops run on to adopt a native filesystem API that allows a satisfactory
> implementation of D-VFS. It is equally unrealistic to expect all remote
> system clients to be well maintained for all operating systems.

THat's the whole point of allowing D-VFS to provide its own implementation if
necessary. Besidies, its is not the desktop's job to make up for deficiencies or
bugs in the OS.

One thing that needs to be considered is that it's not really in the power of
desktop apps to decide the filesystem abstraction. Windows, UNIX, and Mac all
have their own ways of naming files, and the only thing sane apps can do is
conform. I think that Mozilla proved quite well that users dislike apps that
refuse to conform...
----- End forwarded message -----


--