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

[Sean Middleditch]

On Tue, 2005-03-08 at 12:04 -0500, gtg990h at mail.gatech.edu wrote:
> > Yes, think of it in terms of "document access" instead of "file access". There
> > is a really big difference between the two in terms of practical usage.
> 
> I don't buy it. What is a 'document'? Is a C file a document? It is when you're
> in an editor, but it's just an input file when you're in the compiler. An IDE is
> a desktop app, and has to handle both cases cleanly, but D-VFS forces it to use
> different APIs for each case. Is a Maya file a 'document'? Most artists would
> consider it to be such, but again, when the renderer is churning on it, it's
> just an input file. The file/document dictomy works fine for a certain class of
> users (a Word file is 'just a document'), but breaks down for others.
> 
> Let me give a concrete example of where the document/file dichtomy breaks down.
> Say I'm editing a latex file remotely in gedit. Would I then have to use
> something like FUSE to allow pdftex to process the file? What if my server only
> allows one connection per user? Do I just give up and say, "well, that sucks,
> but at least D-VFS works on FreeBSD!"

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.

> 
> I read the link you referenced, but it doesn't support the D-VFS design (and I
> wasn't aware that D-VFS was a document store anyway). Yes, seperating user files
> from system files is a good idea. No, creating barriers for 'legacy' apps that
> need to access user files is not a good idea. Going back to the TeX example ---
> clearly a latex source file is a document. The user will want it stored in their
> document store, and indexed along with everything else. The user will not want
> to have to copy it out or something equally silly just to use it with his or her
> other apps.

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.

No, it doesn't help apps that want to directly access the files, but
nothing short of a port or FUSE-usage can fix that.

> 
> > If you have doubt about that come back after you have compiled your kernel
> > from floppy disk.
> 
> Who uses floppies? Certainly, you can compile a kernel on something like an iPod
> or a fast network drive.

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.  But just
because your view of the world is extremely limited (limited solely to
wealthy people running Linux, apparently) doesn't mean that D-VFS
screwing over the rest of the world is a good idea.

-- 
Sean Middleditch <elanthis at awesomeplay.com>