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

[Sean Middleditch]

On Tue, 2005-03-08 at 17:29 -0500, gtg990h at mail.gatech.edu wrote:
> 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.

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.

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.

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*.  But that isn't D-VFS's problem.
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.  And it isn't even
necessary since it can be done after the fact.

> 
> > 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.

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.

> 
> > 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.

Here's the rub - either you hack the kernel/libc, or you port the
application.  That's it.  D-VFS is *not* a kernel hack or a glibc hack,
it's a cross-platform API.  That means a *new* API.  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.

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.  I'm not discussing this any further unless you have some real,
concrete, useful input to D-VFS itself that can assist with the
solution.  Thanks for your input so far.

> 
> Sincerely,
>     Rayiner Hashem
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>