Dataloss with nullify

[Paul Stone]

I've just come across the following situation, and I'm not sure it's a
problem with the way I'm using mobwrite, or a weakness in the
protocol:

I have a form (say, an article) that uses mobwrite. To store changes
your permanently, you must hit the Save button. If you leave the page
any other way, (e.g hit cancel, or click another link on the page)
then your change is discarded (by setting mobwrite.nullifyAll
onunload)

This works fine - if two people are viewing an article with some
modifications, one person can leave without clicking save, and the
other person can carry on editing it. If both people leave without
clicking save, then the changes are discarded. If this didn't happen
then people viewing the page later will see the 'abandoned' version of
the article, rather than the true persisted version of it from the
main database.

The problem occurs if one person is editing an article, but another
person views the page, and then quickly leaves and re-enters it. This
could happen if the second person hits the refresh button in the
browser. If this all this happens in between syncs of the person who
is editing the article, then all their unsaved edits are lost. This is
because the refresh causes a nullify followed by a sync of the
unedited article. When the person editing the article next syncs,
mobwrite will undo all their changes.

Am I doing the 'wrong thing' by calling nullify onunload? Or is this
something that could be fixed by changing the protocol?

BTW, sorry for all the posts recently - I'm still trying to fully
understand mobwrite and all its intricacies.

[Neil Fraser]

2009/10/29 Paul Stone <pa...@pdjs.co.uk>:

> Am I doing the 'wrong thing' by calling nullify onunload? Or is this
> something that could be fixed by changing the protocol?

I think the nullification call from within the onunload makes the
system much more eager to drop data, since it will do so without the
explicit desire of the user. Nullification was intended for use with
a Cancel button. Might I suggest instead that a short view/text
timeout be used on the server-side instead? This does increase the
chances that a visitor would stumble into an unsaved version that had
been implicitly abandoned. But that's an unavoidable risk no matter
what one does. Consider the case where someone loads the form, gets
distracted by other tabs, has dinner and goes to bed. For 12 hours
that person is preserving a non-default state of the form. This case
would affect MobWrite regardless of timeouts and nullification hooks.

> BTW, sorry for all the posts recently - I'm still trying to fully
> understand mobwrite and all its intricacies.

Keep posting! It's good stuff!

--
Neil Fraser, Programmer & Wizard
http://neil.fraser.name

[Paul Stone]

> I think the nullification call from within the onunload makes the
> system much more eager to drop data, since it will do so without the
> explicit desire of the user.  Nullification was intended for use with
> a Cancel button.

Yes, that makes sense. Abandoning an edit, either implicitly or
explicitly with a Cancel button should always be less common than
saving the changes.

> Might I suggest instead that a short view/text timeout be used
> on the server-side instead?

Thanks, I hadn't noticed the timeout settings before. I've now set
TIMEOUT_VIEW to 5 minutes and TIMEOUT_TEXT to 10 minutes.

Paul