POS

[Paul Prescod]

BRIAN SPILSBURY wrote:
> It is transparent in that there is no difference to anything except for
> the garbage collector, and that you can't guarantee that a weak-reference
> won't suddenly point to nil at any given time. 

Right. So it isn't transparent to the system, the programmer or the
user. It isn't transparent.

> the "transparent object oriented file store" is transparent in the sense
> that it is not distinguishable, it is transparent in that the entire
> system is persistent, with the added tools that are useful for the garbage
> collection of complex systems.

What you seem to be discussing is persistency by *default* rather than
transparent persistency. You must still think about persistence in many
applications.

> Also _just_ having a transactional POS kills persistence of execution
> entirely, which is something definately worth considering.

Executional persistence can be built on top of transactional systems.
Hell, executional persistence can be built on top of *Unix*. The real
question is what is the default.

I have another underlying concern about this persistence-by-default
proposal. What does memory maintenance look like to a user? In a OO DB I
would expect to do queries for large objects or objects belonging to
specific programs or search for objects by type. If I run out of disk
space I delete *.jpg or something. But with persistence-by-default,
things are not required to have names. My jpeg viewer might just have
millions of jpeg files stored in its memory and if those objects are
visibile to me *at all* they would not have names. "df" would return:

Jpview 100,000,000MB
	Jpeg-list-object
            JPG 0X2321232 - 200,000MB

The useful things that I want to delete would also be mixed up with the
ordinary program state variables that I am not interested in: "Window
Position", "User Name" etc.

Yes, we could build a file system on top of a persistence-by-default
system, but if most programs are going to do most of their work in the
file system, why bother with the persistence-by-default?

In the end, how hard is it to keep a "state" object and just call a
function (save-state state "path") and then (load-state state "path")?
Just because Unix makes state loading painful does not mean we must make
go to the other extreme and make it totally invisible.

 Paul Prescod