Let's begin SchemeOS
Sun, 22 Mar 1998 21:33:59 -0500
Chris Bitmead wrote:
> If you do the above, then I guess you have an object file system,
> albeit one that is
> a) inefficient - presumably the .lsp files are ascii text
No, they are whatever is the "standard file format" for the operating
> b) not at all transparent. Every load and store has to be
> explicit, which kinda defeats the purpose. Say goodbye to all
> that elegance.
You think that this is a flaw, but it is actually a strength.
People don't want a "transparent" file system:
* they want to know when something is saved (the word "saved" has its
root the word "safe")
* they want to know *what drive* something is on (for reasons of
storage size, portability, security, and physical locality)
* they want to name their data objects
* they want to group those data objects with hierarchical names (at
> c) Not very practical - you can't have object references that
> cross the boundary between one file and another file. This is a
> big killer.
That isn't true. HTML, SGML and "OLE" objects have references that cross
boundaries between files all of the time. Managing those links is a hard
problem, whether you have a hierarchical file system or an "object file
system", because files disappear, drives are removed, and so forth.
> d) Not convenient. You would have to decide on some arbitrary
> break down on how much to store in one file.
This break-down may not be convenient for programmers, but it is very
convenient for users. It is this breakdown that allows me to move a
particular "file" to a floppy disk or send it to a friend across the
> Your above example in SchemeOS with persistent store file system
> would look something like this I guess...
> (set! *user-list* (filter (lambda (x) (member (name x)
> *bad-guys))) *user-list))
Egad. I don't even want to *know* the number of variables defined in
your top level namespace! You'll notice that my examples were in /etc/.
The equivalent in your model is probably something like:
(cadr (assoc 'user-list
(cadr (assoc 'etc *root*)))
That's not so much more convenient, and as soon as you make a syntax for
shortening it, you are essentially reinventing the hierarchical path
> Once you realise that everything should be a lisp object (you
> seem to have realised that already), there becomes this arbitrary
> problem of which objects to store in which file when using a
> UNIX file system. If you have a mail folder with mail messages,
> do you store each message in a separate file, or lots of them
> together in one file?
Probably one per file so that they can be moved and deleted independent
of each other. Mobility defines granularity.
> What if you want a mail message in two
> different folders, but you don't want to duplicate it? In Unix,
> you can't do it.
You make a link. In UNIX you *can* do it, if folders are directories. If
folders are files, then you make a hypertext link (using XML, OLE or any
other linking technology).
> The whole deal with the persistent store is about object
> orientation. That is storing the code that manipulates data with
> the data itself. If there was a /etc/password equivilent it would
> be a collection with methods appropriate for managing users.
That sounds good, but a bug in that software will render your
/etc/passwd inoperable -- like a bug in Word renders a .doc file
inoperable. That's exactly what we should be running away from.
Important data should live in well documented data formats accessible to
any program that wants access to it.
> I must ask you... Why would you want to muck around with a
> conventional UNIX file system at all given all its disadvantages?
> Just for backward compatibility perhaps?
I haven't advocated a UNIX file system. I advocated a *file system* --
e.g. a user-level concept of persistent store distinct from RAM where
objects can be moved around, deleted and otherwise managed indepedent of
the code that created them.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"I want to give beauty pageants the respectability they deserve."
- Brooke Ross, Miss Canada International