Let's begin SchemeOS

[Chris Bitmead]

Paul Prescod wrote:

> > 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")

I tend to agree that people want to know when things are saved.
But why on earth is that an argument against an object file
system?????

>  * they want to know *what drive* something is on (for reasons of
> storage size, portability, security, and physical locality)

I tend to agree. But why on earth is that an argument against an
object file system?????

>  * they want to name their data objects

They most definitely don't want to name every object in the
system, from every cons cell, number, collection etc. Only a very
limited number of objects need a name. A word document is
actually a big collection of OLE objects in a proprietry format.
But you don't want to name every object within there.

>  * they want to group those data objects with hierarchical names (at
> least)

They want to group things hierarchially, but NOT JUST
hierachially. Tree hierachies are only a subset of the infinite
ways people would like to group, index and link their data.

A conventional UNIX style file system is merely a very small
subset of an object file system.

> > 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.

Yes, it is a hard problem. That is why these links need to be
managed as automatically as possible. Objects shouldn't just
"disappear", but yes when drives are moved that needs to be
catered for, and an object file system can do that just fine.
 
> > 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
> Internet.

It's not very convenient for users at all. Like when Word
documents have links to external things, the user never knows
what to do and the recipient of the Word doc is inevetiably
missing things.

With an object file system, this can be made much more automatic.
Just say copy this object and anything that is directly or
indirectly linked to it onto a floppy. There is no problem here.
 
> (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
> system.

I don't much care at the moment whether they are global things or
assoc lists or whatever. Yeah sure, hierarchies are pretty
important structures. Nobody wants to throw out hierarchies all
together. The point is tha hierarchies are much too limiting.
They are just a mere subset of what can be done.
 
> > 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.

Then eventually you get to the stage of having one object per
file, even down to one cons cell per file, because you never can
be sure what you want people to have external links to.
 
> > 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, 

Ok, you have hard links all over the place. Put one object in
each file, and that might be one way to implement a true object
database. A very inefficient one if it's based on a UNIX file
system. If you're talking about some other, to-be-built file
system, that works like this with one object per file, then you
are talking about an object database. Make the path names
transparent and we are talking about the same thing.

> then you make a hypertext link (using XML, OLE or any
> other linking technology).

I can only assume you havn't ever used an object database very
much???
 
> 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.

You've got to be joking!!!!! If every man and his dog knows the
format of an important file/object, then everybody will write
their own code to update it and potentially stuff it up. If
updating important data is hidden behind well defined and
debugged interfaces, updating it can be made safe. That is the
whole point of OO, to stop people updating data in ways they
shouldn't. Instead make methods to update things the right way.
The vipw, was an extremely crude program made to do this on UNIX
with /etc/passwd, but it was never enforced.
 
> > 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.

Being able to manipulate data apart from the code that relates to
them is the antithesis of OO. I suggest you read some basic OO
stuff first.

All I am advocating is removing limitations of conventional style
file systems. You can use an OO file system just like UNIX if you
want to, it's just that you're not limited to that.

-- 
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au