On 24 Aug, 2006, at 08:15, Andi Vajda wrote:
On Wed, 23 Aug 2006, Jared Rhine wrote:
Let's say a hard-core server crash of osaf.us happens, and the
most recent
backups we have are from 3 days ago (more realistically, I'm
shooting for
backups every 4-12 hours) You, as a Chandler user, have had a
busy week and
made a lot of changes in the last 3 days.
Would you want your server-side data to jump back 3 days in time?
What do
you think Chandler 0.7a4 will do? Will all the local changes in
Chandler be
preserved?
Or will the "server win" and all your data on the next
background sync gets changed to whatever's on the server?
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.
In principle, this could be fixed on the client side by remembering
all the ETags we ever synced each resource against, and treating the
re-appearance of stale ETags as reason to believe the above situation
has occurred. It's a little tricky, because ETags are a per-resource
thing, whereas our sync mechanism is repository-wide. You can
probably construct situations where a server crash (or backup) in mid-
sync could cause Chandler to become confused later on down the line.
An alternative is to take into account the resource's HTTP Last-
Modified value as well as the ETag. Used on its own, Last-Modified is
unreliable, but there's probably a way to use it in conjunction with
ETag that would work well.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
