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 _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
