Niels Mayer wrote: > Why invest in "pseudoversions" when they're not really needed. It's just > more stuff to break, maintain, etc.
I don't agree, pseudoversions are needed not just for autosave, but they will be needed for more advanced collaborative features envisioned for the future. Plus, any change is more stuff to break and maintain, not just new stuff. > 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# Filesystems aren't databases. When you work with a file, you know where to look and you're interested in one item. Plus, filesystems are mostly used privately, without hundreds of users lurking in the same directory. Putting pseudo-documents in the same database means that all queries must work around them, which reduces the performance in many ways: - complex queries - bigger indexes - larger files - more memory needed to store the same amount of real documents + extra pseuodoversions - for a collaborative Doodle storage, there will be several updates per minute per edited document per user, and such an intense traffic means that the actual documents will be much slower to retrieve, if the two don't use different databases And the usage patterns of the two types of entities is different. Documents are more often read than written, while pseudoversions are frequently updated. > 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. While this is better than storing in the main table, it still isn't nice. We're using things for something they are not meant to handle. This is called a "hack", and hacks are not good. Hack badly solve problems for lazy people, but will later come back and haunt them. And this means that autosave depends on the recycle storage, so it creates an artificial bond between two separate features. > Niels > http://nielsmayer.com > > > > On Sat, Apr 25, 2009 at 9:05 AM, Sergiu Dumitriu <[email protected]> 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? -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
