Morgen Sagen wrote: >> Instead of making the server keep track of all state, leave ETag as an >> advisory indication of the resource changing. If the ETag has >> changed, go >> ahead and download, but check the version numbers to make sure the >> version >> id has not dropped. If it has dropped, for whatever reason, either note >> that and notify the user of conflicts, or silently drop it and >> overwrite it >> with your copy. If the version id is higher, overwrite the Chandler >> repository with the server copy. >> >> Thoughts on this approach? > > This sounds reasonable.
If we proceed with this approach, what should the specification be for resources where the ETag is changed but the version number is the same? Keep your local resource or overwrite? This situation might arise if another client updates a resource but does not increment the version number. For instance, the Cosmo UI will do this unless/until an enhancement is included there too. -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
