What's a POS??

[Mike McDonald]

>Date: Fri, 09 May 1997 14:01:07 +1000
>From: "Chris Bitmead uid(x22068)" <Chris.Bitmead@alcatel.com.au>
>Subject: Re: What's a POS??
>To: lispos@math.gatech.edu
>
>
>>  It seems in this discussion about POSes, everyone is assuming that a
>>PSO is whatever they've always assumed a POS was. The rest of us
>>haven't the foggiest idea what YOU mean by a POS. So here's some
>>questions about POSes that I'd like you guys to answer so we can
>>figure out what your POS is.
>>
>>Is a POS completely transparent to the programmer and user? 
>
>It is 99% transparent. There might be a commit API. There might be
>locking APIs. In the general case it is transparent.
>
>>The old
>>Xerox Interlisp machines used something like this. You just did your
>>mornal lisp things and then the system saved everything for the next
>>time you came back around. This is the dumplisp/checkpoint approach.
>
>Not really the same thing if I understand you right. You are talking
>about saving the whole state of the system as one big lump. A POS only
>stores changed objects, and new objects.
>
>>How fine a granularity does your checkpointing have? 
>
>Either object level granuluarity or page level depending on the
>implementation, where a page is dependant on hardware size of pages.

  Not size granularity, but frequency granularity. Some data needs to
be "commited" as soon as it's created. Email for instance. Other data
I only want "commited" once in a while. Other data, I NEVER want
commited.

>>How do you handle
>>different things wanting different granularities?
>
>I'm not quite sure what you're thinking of here, but I hope the
>explanation below answers your question.
>
>>If not the above, then does the object builder or the object user
>>determine if the object is persistant? 
>
>It is persistent if it is connected to something else that is
>persistent. There is a single *root* that everything persistent is
>ultimately connected to.

  I don't want EVERYTHING to be persistent. That's as bad as nothing
being persistent. With everything being saved, I now have to go around
and make sure all of the temporary objects I've created get
disconnected so that they'll get GCed instead of saved.

>>Ie, does the object have to be
>>a special kind of object (maybe a CLOS object with a particular base
>>class) 
>
>No base clas.
>
>>or can I tell the POS system to "save" any ole object?
>
>Yep.

  How do I tell it if it's doing this all transparently? More
importantly, how do I keep it from doing it?

>>If it's the latter, how do you determine where the object ends and
>>some other object begins? If you aren't careful, you're going to
>>implement dumplisp. :-)
>
>Transient objects will not be pointed to by any persistent objects,
>thus they will not be saved.
>
>There might be an option to say that a certain slot of this particular
>CLOS class is not saved. That is not the normal case however.

  That's why it's broken. Your version of a POS makes the assumption
that most things are "valuable" and should be saved. That's just the
opposite of the actual case in a lisp developement environment, which
is the case I care about. So, to answer your question in the "Testing
the waters" thread, "You don't want a POS?" No, I don't! I'd much
rather have an object oriented database that allows me to decide what
gets saved and when it gets saved.

  Mike McDonald
  mikemac@engr.sgi.com