Re: Consideration of "saving" files

[Seth Nickell <snickell stanford edu>]

> > This model is already in use on Palm Pilots (the autosaving part at
> > least, not the reversion unfortunately).  
> 
> And, indeed, was around on things like the Apple Newton long before
> that.

(which is incidentally where a lot of my motivation for this idea comes
from)

> > It's a nice way to work, but I think that very frequent auto-saves or
> > a much higher level of reliability will be required before I'd stop
> > missing a way to force a save to disk of a document that I'd been
> > editing.
> 
> Well, I think Seth's suggestion did include a way of forcing a save, by
> "tagging" a document as he put it-- although that does suggest to me
> something that users might only do when their document reached a certain
> signficant state, rather than a paranoid save-for-safety.

On a hard disk I would expect saves to occur as you type, maybe with a
word by word frequency or something on that order. On a floppy disk this
would obviously be somewhat less frequent. The tagging was intended to
replicate the ability to save a significant state for purposes of
archival and reversion, as Calum feels, not to "force" the thing to save
(though I expect we would actually save to disk at this point too). 

> You're right about reliability, though... whenever a new version of M$
> W*rd arrives on my PC, the first thing I do is switch off the auto-save
> because it always seems to cause more crashes and corrupt documents than
> all its other features put together!

I can think of no particular reasons why it would be really difficult to
make a good autosave except perhaps "bad" filesystems that cause
corruption if they are working on a particular area when the power
switch is flipped. More difficult to consider is implementation
details...

I mentioned CVS, but I don't think CVS is a very good implementational
model (or, more likely, RCS since you don't need pserver functionality
etc). Its awfully archaic, and I would prefer something that leaves the
document in its full form as XML and at the bottom provides the
"patches" that got it to the current state so the system can revert back
X number of layers. Leaving all the information in a single filesystem
unit also helps deal with the problem of copying it to less enlightened
systems.

I don't think we're talking about nixing save from every application;
that's not realistic at this point if only because we have to maintain
compatibility with other file formats... but for native GNOME file
formats and applications this might be possible.

-Seth