[Cosmo-dev] Data reversion protection for servers

[Jared Rhine]

On chandler-dev, I've called for resolution on the technical design for how
resources avoid getting reverted if the server data jumps back in time, as
in after a data restoration from backups.

The summary thread is here:

http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006736.html

The current consensus is for Chandler to keep track of a version number, and
avoid overwriting any records which have a later version number.

This will protect Chandler against reversion of changes Chandler itself made
to records.

However, I noted in the bottom of the above message that the Cosmo UI may
need to participate in this scheme, even pre-Beta, if we want to avoid
cross-client reversion issues.  The scenario would be something like:

* System (Chandler and Cosmo) is in sync for resource R at version V1
* Chandler makes a change, now is resource R at version V2
* Cosmo UI used to make a change, now is resource R at version V3
* Air conditioning fails, room heats to 130 degrees, all drives lost
* Server restored from backup, resource at path P is now resource R1
* Chandler syncs, sees ETag has changed, but version hasn't, and replaces
the Cosmo UI changes with V2
* System is in sync for resource R at version V2

If instead, the Cosmo UI increments the resource version number when it
syncs, then we end up at the "correct" V3 not the "incorrect" V2.

Thoughts:

+ Seems like a race condition with a relatively small window (crash occurs
after Cosmo UI change and after backup but before Chandler syncs).  The
system as a whole will not be horribly broken if this change isn't included.
  Even supporting the version number doesn't eliminate all the race conditions.

+ Effort to fix seems pretty small.  Cosmo UI doesn't have the "check ETag
and version changes" problem that Chandler has.  It just would need to do "
resource.version = resource.version + 1" right after it makes a change and
before it writes that save back to the store.

+ Chandler isn't implementing this change until alpha5, as there's a sharing
format dependency.  So this is probably Cosmo 0.6 material, if accepted.

+ I think this almost-1-line change (increment resource version number after
each change) is worth including into the Beta roadmap.  0.016 stickies for a
1-hour change by my estimate :)

+ I suggest I open a bugzilla enhancement, so this idea can be tracked and
included in a much later release without needing to be tracked on any
higher-level roadmap.

-- Jared