Last week, Jared raised the question of will/should happen if the server-side data were to jump back in time, as in after a data restore from backup.
Grant detailed the scenario where the current versions of Chandler would overwrite copies of resources in the Chandler repository with the versions on the server because the ETag has changed. Grant proposed adding the HTTP Last-Modified for each resource to the "has this item been updated" logic. It was agreed by Grant, Andi, BCM, and Jared that Last-Modified would work, with problems for any sub-second changes. Andi also mentioned that comparisons of server time and client times are error-prone. Also, machine times can be just wrong (though Jared says production servers can be assumed to be NTP-accurate). Andi proposed that the server keep resource version numbers and provide that in addition to the ETag for comparison by clients. Jared proposed having Chandler keep track of a version number inside the data for each resource. The ETag would only be used to determine if a resource might have changed; only if the version number is greater Andi wondered why the Hosted Service isn't planning for bank-like levels of data reliability and availability. Jared said that was primarily for budgetary and scope reasons. Open options seem to be: A) Not worry about this issue until after Beta B) Add Last-Modified to the ETag Chandler currently uses to determine if a resource has changed and should be overwritten C) Have Cosmo track a version number in addition to the ETag D) Have Chandler include a version number in the resource and only overwrite resources if the server-side version number is greater than the local There are design implications to having resources conflict (should there be a popup notification etc), but changing the algorithm used to detect valid changes can be done without any UI or interaction changes. === END SUMMARY === Could we work towards a plan of record for this issue? I'm thinking a straw poll on the options at the end of the summary above would be helpful. Any other options that should be put on the table should also be outlined now. For my part, right now I give a +1 to "D", a Chandler-maintained version number. With this proposal, I do wonder how non-Chandler clients might interact with this synchronization version number, but I see no reason they can't update the same attribute if they update the resource. It's possible that this proposal isn't complete until it's worked out if and how the Cosmo UI will need to update the same version id attribute when it updates resources. Perhaps a server version number is the better approach as soon as there's more than a couple clients. If there's consensus on use of Last-Modified or client or server version numbers, then the next step would be to file enhancements in one or more products and see where in the roadmap those enhancements fall. My apologies for biases, mistakes, or omissions that crept into the above summary. -- Jared Rhine <[EMAIL PROTECTED]> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
