Re: Consideration of "saving" files

[Gregory Merchan <merchan phys lsu edu>]

On 03 Aug 2001 04:04:19 -0700, Seth Nickell wrote:
> So looking into the star trek future of GNOME, what would happen if we
> did away with "saving" files, and instead provided a model where users
> could "revert" to document changes using a few different methods (say,
> by time/date or provide a list of changes ala Photoshop 5 undo).
> 
> Saving is a pretty archane way of working...and really isn't all that
> essential for certain sorts of operations. There's nothing we're going
> to be able to do for things like text files...but consider with Gnumeric
> or AbiWord...
> 

There was some discussion of this on GimpNet, though I don't recall what
channel. Along with mention of the Apple Newton, Palm Pilot, CVS, and
some uncommon file systems, it was mentioned that VMS has revision
numbers as part of the file system.

Lest we enter the wrong kind of flame war, let's make a clear
distinction which has too often been forgotten. On Unix, everything is a
file. This does not mean that everything is a file folder or a document;
file is used here as in the phrase "rank and file". All the proposals
and discussions I've seen for eliminating filesystems are actually
nothing of the sort; I find it hard to imagine a useful system that
actually does eliminate files. Documents and catalogues are a completely
different matter, and perhaps someone should spec a "GNOME Document
Catalog System", or some such beast.

> You open a document and starting working on it. The computer will
> periodically write your changes to disk (maybe once a minute, or maybe
> it will vary based on the speed of the I/O device) in the background.
> But the trick is that the computer is storing information with context
> information about the changes... My understanding for the reasoning
> behind "saving" rather than just writing changes straight to disk in a
> modern context is that people will sometimes make changes and decide
> they don't want them.
>

It would be worthwhile to have a system that in addition to a history of
actions or incremental diffs provides a way to "lock down" a document at
some point, perhaps losing the revision history for the purpose of
sending the document as a file for printing or transmission and also the
mere archive of done deeds.

> So lets say I type for a while and decide I don't like the modifications
> I made...I go to the menu and select "Revert changes" (obviously
> something more descriptive than that), which brings up a simple dialogue
> from which I can select / type "15 minutes ago"...and poof I have
> whatever the document looked like 15 minutes ago.
> 
> An advanced user feature would be the ability to "tag" the document,
> which would achive exactly the same function as saving. You can revert
> the document to any tag.
> 
> This seems like a more flexible and human system (and I apologize for
> all the CVS terminology that snuck in here)... I actually use CVS for
> many personal projects / documents specifically to get this sort of
> ability (and of course its more cumbersome than saving because its not
> integrated into my program and I have to save on top of things).
> 

But the CVS terminology is fine at this point. We must have some way to
talk about the things the user never sees.

> This also fits in nicely with the persistence work we've been putting
> into place using gnome-session. It would be very cool if we could get
> GNOME to the point where you could flip the power switch at any point,
> and it would boot back up exactly as you left it.
> 
> -Seth
> 

I mentioned in another thread that xsmp leaves open the question of what
clients should consider relevant to a session. Having a revision number
could reduce the amount of information that needs to be saved.

While such a system is certainly a usability issue, there is a lot of
work to be done for the parts the user never sees. Perhaps the GNOME
architecture needs a new part?

Cheers,
Greg Merchan
(auspex on GimpNet)