[Portland] PortlandVFSProposal

[Diego Calleja]

El Sat, 07 Jan 2006 15:07:54 +0100,
Philip Van Hoof <spam at pvanhoof.be> escribió:

> You see .. a desktop doesn't run using super user privileges. Unless
> you're desktop is called Microsoft Windows 95, of course.

Must be your setup, please read the FUSE documentation before making
such claims...

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/fuse.txt

Section "How do non-privileged mounts work?"



> I'm also wondering how platform independent this can be. It should, for
> example, also work on Microsoft Windows. You see, many desktop
> applications are being ported from and to Windows. 


You've missed the whole point of my email and FUSE. You see, the 
*cool* thing about FUSE is that it does _NOT_ require "port applications".
It just works transparently. You chdir() to a directory (or do the windows
equivalent) and the files in that directory _happens_ to be a userspace
filesystems, but the app does not care about that - it just uses the 
filesystem through the standard native filesystem calls.

As I said this is an disadvantaje of dvfs and common-vfs: You _need_ to
port apps to it becaus it's not transparent.

In fact, since you mentioned Microsoft Windows, I've just though
of yet another reason why dvfs and common-vfs are unsuitable as a
cross-plataform: The apps ported from linux to windows will work
with common-vfs and dvfs, but the thousand of native propietary
window apps will NEVER "see" our open userspace VFS.

In other words: Take konqueror, and port it to windows and make it
use common-vfs. Now try to open a .pdf file in windows which happens
to be in a common-vfs mounted filesystem. Acrobat reader opens, and
acrobat reader is *not* ported, so it can not see the PDF file. There're
two possible fixesfor this:

 o konqueror copies the PDF file to a temporary, non-commonvfs path...that
   is, if there's a way of guessing the app you're going to open supportes
   common-vfs...

 o Build a common-vfs -> windows VFS gateway. In other words, rename
   common-vfs to FUSE, build a fuse clone.


So you just pointed out another reason why common-vfs and dvfs are unsuitable
for freedesktop and linux desktop development: common-vfs and dvfs works in
linux because we control most of the apps which run in our desktops, but we
do _not_ control the thousand of propietary apps which are not using (and are
not going to use) common-vfs. This makes integration between common-vfs and
propietary platforms unsuitable.


The one way of doing this in a clean, cross-platform way is not do it
at all: Let FUSE do the work for Linux and BSDs, let the Mac OS X FUSE
equivalent do the work, let the windows equivalents do the same in windows
(I've seen apps in windows which build a userspace filesystem, ie: apps
which shows you isos as an unit, so there must be a way of doing it...and 
the future microsoft vista has a "virtual folders" feature and the microsoft
shell has some userspace filesystem features), wait for opensolaris to port
FUSE to opensolaris.


Again: VFS is a operative system specific thing. Things like common-vfs
work for some apps just like KIO work today for Gnome. In the real world,
apps using common-vfs in windows are not going to work well with say,
internet explorer; however FUSE-like approachs _do_ work. And Gnome, KDE
and friends should _not_ need to care at all of this: If you wish to
mount a ssh remote filesystem, either your operative system features
a FUSE-like approach and allows you to mount your ssh account or you need
to build a common-vfs approach which breaks completely everything.




> The desktop isn't "just" GNU/Linux on a i386 compatible computer.

Agreed: Which is why common-vfs isn't suitable, since it forgets
about propietary apps.