Mon, 19 May 1997 06:28:52 -0500 (CDT)
> The thing about LispOS is that there isn't this big partitiion between
> the "OS" realm of responsibility and the "application" realm of
> Just because it is an application decision, doesn't mean that it
> shouldn't use one of several different built-in, library, common
> scenario versioning facilities.
I realized this as I was writing. I hope LispOS leaves much more to
the user and less to the OS designers in these areas (do I hear Fare
typing a response?).
> I can imagine that several different versioning objects might be
> written by people to handle different version situations. Applications
> would inherit their objects from a versioning object base class that
> does things the way they want.
> That doesn't mean it is some fundamental part of the OS though. It
> does mean that it is 5 seconds work to implement if when you want it
I think we should base all design decisions on experience, where available.
I vote that any persistent object have a default versioning that is, at
a minimum, very crude, just based on version numbers where the accessing
the most current version requires no specification of version at all. This
would be like the file system versioning available in VMS, which I claim is
superior (as a default) to the lack of versioning. Of course, it should be
possible to defeat this default versioning by setting parameters specifiying
the maximum number of versions to be maintained (setting this to 1 would
mean no versioning).