[CalendarServer-users] Modifying entries fails with evolution-2.6 due to wrong etag

[Cyrus Daboo]

Hi Wilfredo,

--On September 19, 2006 12:13:24 PM -0700 Wilfredo Sánchez Vega 
<wsanchez at wsanchez.net> wrote:

>    a) I still disagree with the idea of putting ETag hooey into CalDAV.

It is a bone of contention!

>    b) We don't have a strong ETag to return at the end of a PUT unless we
> do the equivalent of sleep(1) first.

Right - getting 'true' strong etags is the first step.

>    c) Right now we're using logic
> that lived in web2.dav, not twistedcaldav, so CalDAV's rules don't apply.
> See (a), which basically requires us to override the ETag logic in the
> CalDAV subclasses.

But we already have to override the PUT/COPY/MOVE behavior to cope with 
CalDAV semantics for calendar data so its not much of a stretch to special 
case ETag behavior there.

In any case, at the end of the day I think it will ultimately be up to the 
client folks to say what they really want in terms of ETag-based 
synchronization.

>> One alternative to the weak ETag issue, though, would be to not use
>> computed ETags and instead cache a (definitely) unique ETag as a
>> private property of the resource. The server then reads/writes that
>> value as appropriate and it can always be a strong ETag.
>
>    Well, that ETag has to be computed at some point.
>
>    We could use a checksum as an ETag (and also then include the checksum
> header).  Computing checksums isn't super cheap, but that may be OK if
> it's just at creation time.
>
>    You might think an increasing integer would work, but that doesn't
> work if a resource is deleted and then re-added, unless we're somehow
> going to cache the ETags even after deletion.

A hash of timestamp+uri+counter would suffice if counter were 'global' and 
could be atomically updated without too much overhead.

The other option - a hash of the actual resource data - is not cheap, but 
does have the benefit that PUT'ing exactly the same data on top of an 
existing resource will not change the ETag. But I don't think we need to 
optimize for that case per se.

-- 
Cyrus Daboo