On Sep 19, 2006, at 11:27 AM, Cyrus Daboo wrote:
Well of course there has been much debate about the CalDAV specs definition of what servers should do on PUT. CalDAV says that a server SHOULD return a strong ETag when PUT does not change the data being stored (which is currently always the case with our server - but may not always be true in future). Clients then know that if they get back a strong ETag, there was no modification of the data on the server and hence no need to follow the PUT with an immediate GET to see what changed. In the absence of a strong ETag, a good client ought to GET the data it just stored with its new ETag just to stay in sync.
Right, but: a) I still disagree with the idea of putting ETag hooey into CalDAV.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. 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.
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.
-wsv
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ calendarserver-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/calendarserver-users
