http://www.abisource.com/mailinglists/abiword-user/99/November/
At 08:18 AM 11/17/99 -0600, Jeff Hostetler wrote:
>> I purpose a option to automatically save to work to say,
>> ~/.Abisource/word.autosave/...
>
>you probably want to consider just putting it in file in the same directory
>with the original document. this might help it keep from getting lost...
If anyone's seriously considering implementing a feature like this, it's
important to be clear on which design model for autosave we're talking
about. I know of at least two, plus two orthogonal ones:
1. Just crash recovery.
------------------------
One approach that I vaguely remember from old versions of Word on the Mac is
session-oriented, fairly transitory, and whose sole purpose is to help you
if the machine crashes.
In this case, we'd always automatically save a spare copy of the documents
you're currently working on in a single known location. These are blown
away just before the app shuts down normally, and probably as each document
gets successfully saved.
That way, on launch if there's anything in that spot, we'd attempt to
"recover" those files (perhaps warning the user what happened, and letting
them look at the results and decide whether they're worth saving). As long
as you never crash while running the app, this approach never kicks in.
Files only get saved when the user chooses.
2. Autosave in place.
----------------------
I believe that this is what Jeff is thinking about. It allows any file to
be autosaved in place, but this feature *must* be enabled on a per-file
basis (not globally and not by default).
Allowing certain files to be automatically saved can be a convenience in
certain situations. If you know that the version you're currently typing is
always more useful to you than the last version saved to disk, then this can
be a convenient feature for some people.
However, other people in other situations work differently. In this other
mode, the changes you're currently making may or may not be more useful to
you than the last version you explicitly saved. You always want to make an
explicit choice when to save a new version, thus deliberately replacing the
last saved version with something that's definitely better.
3. Fast-save.
--------------
This isn't really either of the first two (although something like it can be
used as a technique for implementing either of them).
Our current file format that we save to disk is a straightforward linear
description of one state of the document. By design, it's very easy to read
and work with.
In memory, we use a very different representation of the document (piece
tables) that's much more complex, to allow for efficient editing, and
especially for infinite undo/redo. When we save out the document we convert
from this representation to the (much simpler and cleaner) file format. A
very similar conversion is continuously happening in order to show you the
current state of the document, so this process is already tuned to be quite
efficient.
In practice, keeping the two separate is a very very Good Thing. (Your
head-in-the-clouds CS prof was right on this one.)
Fast-save violates that rule. Why? Basically, it's an archaic feature from
when Macs and PCs were painfully slow. Users complained that some documents
took "too long" to save.
So, instead of translating between two representations like this, some word
processors hacked out a speedup by just blindly dumping a copy of the entire
messy in-memory representation to disk pretty much as is. (Indiscriminately
copying big chunks of memory is always faster than doing anything even
slightly intelligent with smaller chunks.) It's terribly wasteful of disk
space and can introduce *tons* of compatibility problems. However, at the
time, it gave them a speedup users could notice, so they did it.
4. Version save.
-----------------
Again, this is yet another class of features. How you implement it depends
on what granularity of changes are interesting to a wide-enough variety of
users.
On one end of the spectrum, it's technically possible to preserve every
change ever made in the entire lifetime of the document at the keystroke
level. That's a *lot* of information to hang on to, and can take a lot of
resources (disk space, memory, and time) just to keep track of it all. This
is exactly what's done during a single session to implement infinite undo,
and Jeff's quite capable of extending that mechanism to go back in time
forever.
However, you'd be surprised how much of that information is useless. When
you step through that kind of data, you'll find that very few people type as
cleanly as they think they do.
Don't believe me? The next time you spend an hour typing without closing
your document, keep hitting undo until it stops. :-) Then remember that
any decent undo implementation has already done a lot to compress that
history and smooth it out for you. Now imagine a document that you've been
working on for a year.
A more compact alternative would be to just keep track of discrete changes
from version to version. However, this is likely to require a different
mechanism to do it properly. Until someone's ready to try to implement
this, I'll hold off on exploring the design alternatives.
bottom line
-----------
I haven't thought enough about this to know which design I'd prefer, but I
wanted to make sure we all have a common vocabulary for discussing the
implications of various design choices.
>As for the file format, i wouldn't want to add this to the .abw format.
I agree. Word did this to their file format a long time ago, and have
created an unholy mess. Let's not repeat that mistake.
Paul