Hi Wilfredo,
--On September 19, 2006 12:13:24 PM -0700 Wilfredo Sánchez Vega
<[EMAIL PROTECTED]> 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
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
