[cap-talk] Persistence and Versioning (this is how easy it really is)

[John Carlson]

On Mar 13, 2008, at 11:58 PM, Jed Donnelley wrote:

> At 10:36 PM 3/13/2008, John Carlson wrote:
>> I think that when you bring up persistence, you need to start talking
>> about versioning in the same breath.
>
> I don't believe so.  For me the persistence of storage
> (e.g. files) suffices to build a versioning system (e.g. all
> the examples built on Unix).  From my perspective the underlying
> capability system needn't itself support versioning (and
> indeed shouldn't for reasons of simplicity in the most
> trusted software) for higher level software to do so.


If you build it into the higher level software, then every single  
application has to implement it.  If you implement at a lower level,  
then every application
can take advantage of it.  It's like asking every application to  
implement commit and rollback in it's own code instead of providing it  
as a base service in the database.  Perhaps I should read back about  
how checkpointing is done in a capability system.  The lack of a  
required API at a low level allows lazy programmers to not implement  
versioning, and users suffer.  If you can't insert data into a  
database without doing a commit, this forces the programmer to allow  
for rollback.

I guess there should be a required call in the GUI for the programmer  
to see anything change on the screen.   This might be the best way to  
force programmers to implement undo/redo.


If you have persistent processes that deal with files, how do you  
upgrade your files to agree with new persistent processes?  Wouldn't  
you like your files to change at the same time the persistent process  
changes?  What if adding a new column to your database automatically  
updated your application or vica versa?  Ruby is doing some of this.

John