POS

[Paul Prescod]

BRIAN SPILSBURY wrote:
> You must have a different definition of transparent to me, please tell
> me what it is.

Transparent means you can't really see it. That which is on the other
side looks the same as if "whatever" wasn't in the middle. Persistence
should not be totally transparent because a) users explicitly WANT to
manage it and know what is stored there and b) programmers often want to
manage it because sometimes they want to force a commit 
 
> > What you seem to be discussing is persistency by *default* rather than
> > transparent persistency. You must still think about persistence in many
> > applications.
> 
> When I don't have to take persistence into account to interact with
> objects then persistence _is_ transparent in my book.
>
> The only point at which I might need to take persistence into account
> is where I'm creating an object whose persistent characteristics are
> not the default. And that is not terribly common, and certainly should
> not be visible to the user.

Most of the apps I write have different persistence characteristics.
They do a lot of work with data that should not be saved to disk and
then return a little bit of data that SHOULD BE. So you're making your
apps easier to write and making mine either harder (I must explicitly
tag hundred of objects "not persistent") or slower.
 
> Executional persistence requires underlying support in the memory
> system. If you have a stack it must be preserved, if you refer to
> anything outside that stack that is not necessarily referenced
> though your transactional database you'll have trouble.

None of that requires *file system support*. It requires runtime
support, but not *file system support*. Why not just have a function:
"(save-my-state)" that saves the current state. In fact, in Scheme I
would write it this way:

(define (save-my-state path)
	(call-with-current-continuation
		(lambda (continuation) (write continuation path))))

That requires a standard format for continuations, of course.
 
> Executional persistence in unix is a nuisance, and sometimes unimplementable
> simply because you may have libraries mapped in at different locations
> in which case function pointers may now point into 'interesting' spaces.

That has nothing to do with the file system.
 
> > 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.
> 
> Think about a macintosh program. It has things called resources.
> You can delete them if you like, just don't expect the program to
> necessarily run afterward. Your point doesn't seem valid. If its
> referenced by a program then that program should be using them, if its
> not using them, then it shouldn't reference them.

It has a "weak reference" to them. It is okay to delete them. The
problem is that they are *named* but without a system-wide file system I
may not be able to find the names. What if the names are stored in a
vector in one place and the actual graphics are in a vector elsewhere.
Another program could store them as tuples (name, graphic). Another
program could store them in a hash table. That's why it is important to
have a *standard* for organizing things with names so that users can
recognize them.
 
> Most programs don't need to use a file-system as a place to store files
> reachable by others. A filesystem is only useful as a registry in which
> other things can seek out stuff without you explicitely telling
> them about it.

Right. I think that everything should go into the registry so that users
can manage it from standard programs ("ls", "df").
 
> > 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.
> 
> Speaking from experience, almost completely impossible.

What's so difficult about my save-my-state function? It should work fine
on the Unix file system or any other operating system as long as there
is an external representation of continuations. But that's a language
implementation issue, not a file system issue.
 
 Paul Prescod