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

[gtg990h at mail.gatech.edu]

Quoting Sean Middleditch <elanthis at awesomeplay.com>:

> Ah, but only one connection per user is one of the reasons for a daemon
> in D-VFS, and FUSE can use D-VFS.  But hey, guess what - if you don't
> think FUSE is up to snuff, what in $DEITY's name do you expect D-VFS to
> do for legacy apps?  You either must use FUSE (or something very much
> like it) or you must port the appliaction.  There isn't any other
> solution.

Ok, so I have to drop down into a CLI, and mount the D-VFS share over FUSE? At
the same time, I have to deal with the fact that my file now has two different
names, depending on the program. How is that in any way better than KIO or
gnome-vfs? You see me to agree with me that this isn't ideal, but disagree that
there is another way. Well, there is another way. Have D-VFS act as a layer on
top of the native filesystem. D-VFS names can then look like native filesystem
names, and the user only has one namespace to contend with. On top of that,
desktop apps can get all the advantages of a "better" API, while apps that don't
need such an API can still get remote file access.

> Just as an aside, something that would probably be useful would be a
> 'vfscat' command that can read and write VFS files and pipe to/from
> stdout/stdin.  vfscat dav://server/elanthis/list.txt | sort -u | vfscat
> dav://server/elanthis/list2.txt.  Other variants would be vfsls, vfscp,
> vfsmv, etc.  Assuming that they recognize when a local path is given
> instead of a URI, you could even replace the normal version of those
> commands with the vfs versions and get transparent D-VFS support for the
> common tools.

So you agree that integration with the CLI would be useful. How can you possible
think, though, that an rewriting the UNIX userland is a good way to achieve this
integration? Most apps will never be rewritten to use D-VFS. If a consistent
user experience for something as basic as file naming requires rewriting
existing apps, there will never be a consistent user experience on a D-VFS
system.

> Only most of the world.  Perhaps you are lucky enough to live in a
> wealthier area where you *can* afford an iPod.  Hell, I do.

My point had nothing to do with floppies (it was a lame attempt at humor). My
point was that floppies are a terrible example of what people might want to use
D-VFS shares for. Sure, you can't compile your kernel on a floppy (implying that
you don't need D-VFS for stuff like kernel compilation), but you might want to
run pdftex on an ssh drive.

I'm saying that you can't try and draw a distinction between "documents" and
"files", and say that D-VFS is only for files, when that distinction breaks down
in many real world scenarios. Another example: it seems entirely reasonable for
a person to want to use Bluefish to edit a website on an FTP drive, then want to
run html::lint on it, without having to contend with two different file-access
paradigms.

Sincerely,
    Rayiner Hashem