continued: Common-VFS proposal

[Havoc Pennington]

Hi,

Here's one way to think about it: the VFS should expose a more user-
oriented conceptual model of what can be done. So e.g. we would like to
write apps to APIs like:

 - save document
 - open document
 - move document
 - throw away document
 - find icon and default app for document
 - set preference
 - get preference

Those are the things desktop apps want to do. For most other things they
might want to do with the filesystem, using a VFS is probably wrong. For
example, say my app wants to use mmap() for a cache, or to quickly
access a huge graphics file. That should use the UNIX APIs *directly* in
my opinion, because you are deeply relying on having a fast local store
with particular semantics. Also in this case you are probably creating
something in /tmp, /var, or a dotfile - i.e. user-invisible
implementation detail.

The VFS should essentially be the backend for the file manager and
open/save menu items, and prefs should go through a dedicated prefs API.

Which leads to another design parameter for the VFS: what's being
abstracted is *user file access*, another way to think of this is non-
dotfiles in the home directory, plus shared network folders etc.

Replacing all file access in an OS with a desktop VFS would not be
desirable. /usr etc. are internal software implementation details, not
user data. You don't want ld.so reading from a desktop VFS, or e.g. to
use the VFS to load .desktop files and icons from /usr/share. Those
things are best done with simple plain old file APIs (either UNIX
directly, or some kind of simple cross-platform wrapper).

If you don't cleanly separate the various purposes of the filesystem
(user data, prefs, implementation of the OS itself) then getting the
right design for the APIs is difficult at best.

Havoc