On Thu, 24 Aug 2006, Grant Baillie wrote:
I sure would hope so. It would be a shame if chandler lost local, more
accurate, data due to the re-syncing of old, out of date, data.
Hope is not enough :). If you think it through, people end up losing changes
in the current scheme, viz:
1) Let's say a user has synced an item in Chandler, and that corresponds to
an HTTP resource with ETag E1.
2) The user changes the item and syncs, which results in a PUT on the
resource, with the ETag now becoming E2.
3) The server crashes, and the restore rolls back its to state to where it
was in 1).
4) The user syncs. We know the ETag when we last synced was E2, so we notice
it's now E1, which is not a value Chandler knows about. So we pull the old
version from the server, and wipe out the user's changes.
That's why I was talking about server version numbers. Using ETags + a version
number might help in determining that the ETag is older than the one I'm
comparing it against. The server version number would be the same as an svn
revision number.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
