Why invest in "pseudoversions" when they're not really needed. It's just more stuff to break, maintain, etc.

Is there any reason why the draft can't be autosaved in a similarly named document ... for example emacs autosaves files with '#' leading and trailing, e.g. #cspanplayer-embed.vm#

When the document is explicitly saved, the autosave is deleted. On document edit, if modify-time of the autosave file is later than the file it is autosaving for, pop a dialog with the times & sizes & a "diff" which allows the user to choose whether to edit the orignal file or continue editing the autosave file. If autosaving to a similarly named file isn't considered elegant, how about reusing the existing mechanisms of the recyclebin. Autosaves go into the recycle bin, using its facilities keep track of the original document associated with the auto-save. They can be recovered by deleting the original and restoring the auto-save.

Niels http://nielsmayer.com On Sat, Apr 25, 2009 at 9:05 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > Hello devs, > > Auto-saving the content during long edit sessions, to prevent the > complete loss of data in case of browser or OS crashes, > (http://jira.xwiki.org/jira/browse/XWIKI-1581) is a pretty useful > feature that people have been asking for. > > For 1.9 there will be the possibility to enable autosave. However, the > implementation is pretty basic, more of a hack on top of the current > architecture: an asynchronous JavaScript calls periodically save & > continue, marking the saved versions as minor and setting the version > comment to "(Autosaved)". This approach has some obvious disadvantages: > - A lot of minor versions are created during the editing > - Cancel does not undo the changes (a revert could be done to the > version at the beginning of the editing session, which creates yet > another document version) > ... but at least it's a start. > > For properly implementing this in the future, some important changes are > needed. In particular, the support for pseudoversions > (http://jira.xwiki.org/jira/browse/XWIKI-500). Pseudoversions are > temporary versions of a document being edited, and can be seen as > short-lived versioning branches, resulting in a one official version > when the user finishes editing the document. These pseudoversions will > be memorized in a new table, similar to the document table or the > recycle bin. > > Along with introducing pseudoversions, several behaviors should be > changed, improving the user experience. For instance: > - In all editors, "Save & Continue" should become "Save draft" and > should create pseudoversions that can be canceled, and "Save and View" > should become simply "Save" (these texts are also much easier to > understand by the user). > - In class editing, properties are added in the pseudoversion, and these > changes can be canceled when the user presses the "Cancel" button. > (canceling property addition is not possible ATM, unless the document is > reverted). > - In the object editor, objects can be added in the pseudoversion, and > all changes can be saved at once. > > These changes are pretty substantial, from the data management and user > experience point of view, but I believe it is worth making the step. > > Please tell me what you think. Should we try to get this done before 2.0?