virtual filesystem ideas

[Thomas Leonard]

On Mon, Sep 22, 2003 at 01:21:19PM -0700, Ken Deeter wrote:
[ missing attrib ]
> > In the ideal world, apps would use the vfs for all file access. Not all
> > file access is of the form "user asks the app to load a file". Much of
> > it is things that happen automatically, in the background, or as small
> > parts of everyday program work. When loading an icon for display you
> > can't have the vfs automatically poping up dialogs for you.

Why not? This is exactly what we do with Zero Install, but after a short
time-out (1/3 of a second). So, if the icon can be fetched in that time
(cached, or the network is quick) then the user doesn't see anything, but
if there's a holdup then the user can watch a progress bar, cancel the
download etc.

We use DBUS (the protocol, not the whole daemon) to communicate between
the downloader and each user's progress monitor. Applications request
files using the usual POSIX calls, and a kernel module dispatches the
requests to the downloader if they're not already cached.

Non-Linux systems could LD_PRELOAD replacements for the POSIX calls. While
such systems would run slightly slower than a normal system (or one using
the kernel module), an extra check for each file op is exactly what you
need, unless you want some operations to fail for remote files.

VFS libraries can offer extra calls (async versions of read(), etc), but
all the basic calls (open, exec, etc) have to work on virtual paths. And
it has to work with all applications, including shell commands.
VFS paths that only work 50% of the time seem pretty useless.

Although the design requirements for 0install are slightly different to an
FTP filesystem, the basic concept is the same. There's an architecture
diagram here, if anyone's interested:

	http://zero-install.sourceforge.net/technical.html


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1