The feel of a LispM/List of running machines

[Chris Bitmead uid(x22068)]

>  The point is, that for people who would like to retain UNIX
>  compatibility, an arbitrarily advanced or complex Lisp file system can
>  be implemented on top of a UNIX file system. That doesn't mean that
>  the facility has to be any less seamless or any less "part of the
>  LispOS".
>
>Maybe. We have and sell a graphics system running on ACL and
>cross-platform on IRIX and Windows NT, and one of the non easy things
>is to share code to deal with pathnames.  One problem is that ANSI-CL
>is trying to implement pathnames as a virtual file-system, and that
>creates a lot of troubles (e.g. extension is a slot in a pathname,
>but the concept does not exist in Unix). I'm not that sure that it is
>a trivial problem to have a generic interface to many different
>file-systems. 

I don't think we are talking about the same thing.

What I'm saying is that we can store things into UNIX files at a
particular level of granularity.

1 Lisp Object = 1 UNIX file is definitely NOT the right level of
granularity. It is too fine. Rotten performance.

1 Lisp FILE SYSTEM = 1 UNIX file is NOT the right level either. Too
course. Inability to give disk space back to UNIX.

Many object databases have the concept of a "segment" which is a
logical area of the database to allow grouping of related
objects. This helps with performance.

The concept seems essential for a OOFS (object oriented file system),
so that you can specify which machine/disk you want an object at a
minimum. It should also specify a logical segment within that file
system to store an object.

I envisage that such a segment would be (in the case of a UNIX file
system implementation) mapped to 1 UNIX file.

Thus, one UNIX file might for example, store all the config files for
the FooBar application. Another UNIX file might store all your WP
documents. Any security or file attributes or ACLs or whatever your
favourite file system feature is you want implemented would have
nothing whatsoever to with the underlying UFS file or its file
attributes. They would be stored as Lisp objects *within* the UFS
file.

But all this would be invisible from the point of view of LISPOS. You
wouldn't know what the underlying implementation was doing with your
objects. All you would see is the logical segment, which is a
necessary ingredient for any OODB or OOFS anyway.

The issue of using other types of file systems like UFS and ISO and
fat within LISP applications "AS IS", (i.e. not as mere repositories
for the you-beaut cool OOFS) is a separate issue, and not a very
interesting or exciting one IMHO.