i thought about adding it in the fall of 98 when doing the piece tables, but
had other more pressing things to do at the time.... (i wanted the incremental
change file as a testing tool to help with some automation testing....)
> 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...
> In order to do this effectively, is to perform
> the task in a different thread. Does AbiSource's framework have a
> pthread_create equivilent call? That is, a function that takes a function
> pointer as a parameter, creates a new thread, then execute that function in
> the background? I know windows and linux has a rough support for it, but is
> there any functionality in the framework?
currently we don't use any threading in abiword. we have some design notes
for adding it for background printing, file open/save, etc, but haven't done
anything about it yet....
> Another idea is to emulate the "fast save" feature. Since we keep all changes
> stored in the undo buffer (hopefully), we should be able to just append the
> changes to the abiword doc. It would not take too much additional code, just
> in the saving and the importing bit.
we use a PieceTable with complete undo/redo -- it's a rather "involved" data
structure.... everything is complicated when dealing with it.... (... sorry,
i saw the word "just" and couldn't help myself :-)
> Let me explain a little. On first save, the document is saved as normal.
> Then, every 5 min, or so, all the changes to the document would be appended in
> some sort of <abichanges>...</abichanges> section which would provide a sort
> of diff approach, but not line by line but actual changes. If we have the
> redo (reapplication of an undo) functionality implemented in abiword, we
> should be able to load the orig document followed by all the abichanges, then
> use the redo functionality to rechange/reapply everything. That is atleast
> what Word does, from what I could gather.
>
> So, if we have the undo/redo fully functional, fast save should not be too
> hard to implement. And with threads, all of this could be done in the
> background, (in addition to printing, importing, ...)
The place to add this is probably as a new DocListener (we have a bunch
of 'Listeners', a "DocListener" receives the intial document contents and
formatting (as a series of populate messages when the listener is installed)
and then all of the change notifications (as a series of change messages).
We use this mechanism to allow multiple views to 'attach' to a document
and in-effect receive callbacks when the document changes so that they
can update the screen.
The AutoSaveDocListener would listen in a similar fashion and on change
messages push information to a fast-save type file -- either with absolute
information (the entire original document) or relative to the last save.
To be fast, the listener should only write out things ever so often (say
every 10 or 20 change nofications).
If we go this route, there is no need for threads.
As for the file format, i wouldn't want to add this to the .abw format.
it'd be better to define an (ascii) format that would be a series of
records of various types. we could use XML, but that would be
optional. The file format would be something like you'd expect to see
in a testing tool. I can elaborate on this if anyone is interested in pursuing
this. (think of serializing the ChangeRecords (in ascii or xml) and using
indexes to the IndexAttrProp's)
jeff