pathnames

[Chris Bitmead uid(x22068)]

>> >When it is finalised, the path object is told to close it down.
>> >It does this by storing the string back to the file.
> 
>> This implys that things are stored back to disk in a non-deterministic
>> fashion. That implys that in the event of system failure you have got
>> no consistency of data whatsoever.
>> 
>> No, I think you have to do it properly and have a (commit) API.
>
>Hmmm... that breaks the abstraction of persistent objects, though.

I don't personally see how. Can you expand on this statement?

>> >Directories do things like return lists of the path objects
>> >they contain - but their most important task is to accept
>> >new objects.
> 
>> Why call it a directory then? It's just a data structure, like
>> everything else in OOFS. It may be a list, hashtable, vector,
>> structure, queue, btree or whatever.
>
>It's expected to comply to a small API such as giving a POD
>(persistent object description - name, type, versions available
>with mod dates, etc) for any object it contains, etc.

Why do you want to comply with such an API? Who says you want to
artificially give everything a name? Naturally everything has a type,
because we are talking lisp. Mod dates? Well, do you really want every
cons cell on the system to have a mod date? Sounds like a lot of
wasted space.

Versions? Well also don't forget that nice Lisp code is very
functional, and not everything will have a clear correspondance to a
version.

Take mail for example. There will probably be a list of mail articles
for each user. When the system gets more mail it will probably create
a new list containing the old plus the new mail and store the new list
in the well known place where people's mail folders are kept. The old
list would be kept as an old version.

But there wouldn't be a separate version for each cons cell, or each
piece of email. The new version folder would simply point to the old
email. (A nice space saving over UNIX!) In fact there will be a
relatively small number number of objects in the system which need
versioning.

Let people inherit whatever behaviour they think appropriate for their
objects.

>This exists so we can be sure of providing a user-level representation
>of what's in there, without having to actually access each object
>(ie, by having a "represent-thyself" method), which would cause a load
>of disk thrashing when we look into a directory!

Unlike a UNIX fs where every file has it's own inode which points to
separate disk blocks and every file has at least one disk block
attached to it, OOFS is much more efficient, like an OODB. In most
cases, all the objects in a collection (or directory if you must use
that term), should be on the same disk block. Therefore it will be
much more efficient to access each object in OOFS than to even do an
"ls -l" under UNIX, let alone a "file *" under UNIX.