pathnames

[Alaric B. Williams]

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

Sure :-)

What I meant was, the persistent system implementation rears itself
in two places, one of which is invisible.

A) It provides a user-level method of selecting these persistent
large-scale objects - printers, people, documents, etc. Given a user's
guidance, an application can get hold of an object that uniquely references
a persistent object without having to drag the object out of it's storage,
which might be on the other side of a 300 baud link!

B) When such a path object is "opened", a function that returns the actual
object associated with it, the illusion of the object being in first-level
storage is set up by the object being simply returned, after having been
reconstructed from the pertinent binary format (UNIX filer, LispOS POS,
totally virtual entity, etc) - so we don't see the dirt of it's
reconstruction. What's more, when it's time to GC the object, it's
state is then written back (invisibly) to where it came from, for
later reference.

I think that having a commit API would then make the two-level storage
nature of those objects that just happened to be in the user-level
"namespace" have to be dealt with differently, all of a sudden - they'd
have to be committed and all that.
 
> >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.

That's the point. Only objects registered as persistent have to have all
this data.

Ultimately, all objects are persistent, since even if they're not
directly persistent, they're inside a persistent object.

EG, the user-level repl loop is in fact a persistent object (maybe
called "/bin/sh", as a subtle irony :-), so everything inside it has
a home to go to when the system is powered down, but only the actual
environment object is registered as persistent, since it includes
everything else. It would have modification dates and all that, and
a user-level type. It's real type would be "executing environment
with a continuation", but it's user-level type could be "Command
line application".

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

It's nice for document management, and the user-level POS is a very
stateful thing rather than functional.
 
> 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.

Yes, mail shouldn't be handled with files a la UNIX. Perhaps a "mail
address" user-level object would be nice, where the user goes to 
write email or read email. They could have more than one address
object. I do.

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

Agreed... so let the default be "no versioning", but make a special
"commit" API where persistent objects can give the OS a hint that
they're in a good state for a checkpoint right now. The OS can store
the list of versions as the "oldest version", then a list of
sets of differences from that.
When it decides to trim off some old versions, it updates the
"oldest version" with them, then drops them.

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

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

Yes, but these user-level objects (which would map nicely to
segments in an OOFS from what I hear) are typically going to be
relatively large.

ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html