Persist or not persist : comment
Thu, 21 Oct 1999 15:34:36 -0700
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.
> 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
> 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,
> 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
> 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
> 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
Again I emphasise: _look at Udanax_. It has possibilities for version
control like I've never imagined before. It's AWESOME. And free.