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

[John Carlson]

Journaling file systems are an example of putting this kind of  
versioning at the lowest level, and I think, in all, journaling file  
systems have been very successful.  I don't see a whole lot of  
difference between a journal and a versioning system, but perhaps  
there is.  I'm not suggesting that journaling file systems provide  
POLA, or that a versioning system could provide POLA.   These are just  
features that would be nice to have.  Where they are ultimately  
implemented needs to be evaluated.

John

Begin forwarded message:

> From: John Carlson <john.carlson3 at sbcglobal.net>
> Date: March 14, 2008 1:06:19 AM PDT
> To: "General discussions concerning capability systems." <cap-talk at mail.eros-os.org 
> >
> Subject: Re: [cap-talk] Persistence and Versioning (this is how easy  
> it really is)
>
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080318/3eff64cd/attachment.html