Persist or not persist : comment

[btanksley@hifn.com]

You forgot to include the group in your reply.  Deliberate?

> >At the same time, a 'Document' object would be expected to 
> have a 'save'
> >method (perhaps "commit" would be a good name) which simply 
> makes all the
> >changes official.  The user doesn't ever HAVE to hit that 
> button marked
> >Save, but they certainly can.

> >Now, when you add in Udanax-style version management, the 
> whole usefulness
> >of saving documents gets a little more doubtful.  I think 
> Tunes should be
> >based primarily on Udanax algorithms (although probably not code).
> >Especially since they're unpatentable.

> This isn't quite the full picture.

Oh?

> Take for example the idea of a
> journalling file system, which is a rough analog of a fully persistent
> system, only taken at low-level.  The stored object's 
> _representation_ is a
> series of states linked by operations on those states.  The semantics,
> then, of a GUI lement like "save" would be to merely force 
> the store to
> include all updates in the store's cache, the RAM.  To 

Heavens, NO!  That's a direct contradication of what it means to be
persistent.  The save button merely marks a major version.  The document
itslef is already persistent -- it's already on disk.  Of course, part of
the activity of the major release would no doubt be to make sure
everything's committed to disk (safety first!), but that's a minor note.

> perhaps clarify what
> you are doing the word "Make concrete" or "solidify" (yes, 
> "commit" works
> to some extent,

Not a bad idea.  For the immediate future, "save" is better than any of our
suggestions.

> but doesn't connote the idea that 
> data-retrieval would take
> less time)

A very bad idea.  You're restricting the semantics FAR too much.

> might be more appropriate.  At the same time, you 
> don't loose
> the ability to "undo" or "redo" state-changes.  In fact, you 
> retain the
> ability to do so at fine-grain implicitly.  Of course, 

Necessary.

> changes to state in
> practice usually consume a lot more space than the resulting 
> data, so we
> arrive at another factor of the semantics of "save": that of 
> discarding
> previous (dare i say it?) versions of the object.  Of course, 

I would want this to happen as part of a version manager interaction (i.e.
the user asked for it specifically), never as a side-product of a major
revision release.

> in the usual
> systems, one wants safety, so one explicitly differentiates 
> the versions by
> creating new persistent objects (i.e. "save as...").  In file systems,
> these aren't linked semantically, though, so a persistent 
> store would do
> things differently.

I would say that we should imitate Geos -- object persistance, document
saves without loss of version control (although Geos' version control
SUCKS), and a seperate backup button which simply creates a versionless copy
of the document somewhere else.  Three copies of the document at any given
time.

Again I emphasise: _look at Udanax_.  It has possibilities for version
control like I've never imagined before.  It's AWESOME.  And free.

> 	Brian

-Billy