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

[gtg990h at mail.gatech.edu]

> 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!"

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.

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