27 Apr
2009
27 Apr
'09
7:45 a.m.
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 <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?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/