RE: ETags and concurrency control

[Pablo Castro <Pablo.Castro@xxxxxxxxxxxxx>]

Thanks for the feedback. Given that this may be used to decide whether an operation is overwriting the correct "original" version of a resource, it feels like the risk of collisions that come from hashing the values instead of using the values themselves is not acceptable. I'd be curious to know if anybody is using this approach and how its level of correctness is assessed.

Thanks
-pablo


-----Original Message-----
From: owner-atom-protocol@xxxxxxxxxxxx [mailto:owner-atom-protocol@xxxxxxxxxxxx] On Behalf Of Aristotle Pagaltzis
Sent: Sunday, April 27, 2008 10:19 AM
To: atom-protocol@xxxxxxx
Subject: Re: ETags and concurrency control


* Pablo Castro <Pablo.Castro@xxxxxxxxxxxxx> [2008-04-25 02:30]:
> Creating ETags: Astoria can be layered on top of many data
> sources, so ETags can be many different things. We designed it
> so that the developer creating the service can indicate a
> subset of the property of the "entity" (e.g. object, record,
> etc.) being exposed as part of the ETag. In the ideal case
> they'd just use a single timestamp property, but in practice
> that's not always possible. One effect of this is that in some
> corner cases ETags can get big and bloat the header.

Hash the value? (Or allow the API client to request that it be
hashed?)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>