[Chandler-dev] Server-side backups theoretically desirable?

[Morgen Sagen]

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 <jared at wordzoo.com> 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".  :-)