On Sep 1, 2006, at 11:30 AM, Jared Rhine wrote:
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
On Sep 1, 2006, at 1:08 PM, Brian Moseley wrote:
On 8/31/06, Jared Rhine <[EMAIL PROTECTED]> wrote:
C) Have Cosmo track a version number in addition to the ETag
+1
I change my vote to "C" based on the scenario Jared points out, and
Brian's willingness to implement "C". :-)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
