[movitz-devel] On filesystems

[Peter Minten]

Hi people,

I did some thinking about the best way to use filesystems in a hypothetical
LispOS (I'll call it MILOS for now). It seems to me that the old fashioned
one-root virtual fs model is still the most practical, despite the kludges it
causes, because people are used to it and it's a relatively easy to use model.

There is room for improvement however. First of all we should stop thinking
about the virtual fs as the ultimate representation of the filesystem for all
purposes. While it may be good for many purposes, some things require a
different _view_. Such a view could be provided by an application, or by some
system thingy.

Here's an example of views. Say each user has a directory web in his/her
homedir. These directories need to be mapped under the wwwroot of the webserver.
This can be done in two ways: symlinking and instructing the webserver to create
virtual directories. In the latter case the webserver creates a view by mapping
wwwroot directories onto virtual fs directories. It should be clear that the
latter is a better solution than the former.

But now the admin wants to create a wwwroot with subdirs 'students', 'teachers'
and 'managers'. This requires filtering on groups which the webserver can't. To
solve the problem the admin creates a view by writing some simple code, loads it
and sets the wwwroot of the webserver to the root of that view.

A little syntactic intermezzo. A normal pathname is written as $/foo/bar
(/foo/bar in unix terms). A pathname in a view is written as $[viewname]/foo/bar.

Views are nice, but there is more. In the virtual fs that I envision all files
are objects, at the very least subclasses of stream. The class of a file is
virtually unrestricted, as long as it's a subclass of stream and file and/or
directory. Operations on file in the virtual fs are implemented as generic
functions. Thus it's easy to set up translators like in the HURD.

Files also have associated plists or hashtables (the actual implemention doesn't
matter) which can be used to store properties. So one can store whether a file
is configuration, who created it, when it was last backuped, etc. The getters
and setters of properties are also generic functions so that one can set the
configuration attribute and at the same time add it to the configuration view.

Finally the virtual fs will allow custom options for the actual filesystem. Take
for example a CVS FS in which the movitz code is stored. Now say I want to look
at an older version of my code. What I would type is something like:
'(view $/cvs/movitz/losp/tmp/harddisk.lisp[rev=1.1])'. The [rev=1.1] is a
parameter that's passed to the CVS fs.

Parameters can also be used with views (first the view checks if they mean
something, then the actual fs) to get something like a versioned package system.
Say you want to load the 1.1 version of movitz: '(load
$[pkg]/movitz[version=1.1]/load.lisp)'.

Ok, that's all for now.

Greetings,

Peter