Hi Peter, --On January 5, 2010 3:21:34 PM +0100 Peter Mogensen <a...@one.com> wrote:
I'm considering using Varnish in front of CalendarServer to cache iCalendar data for calendar-collections.
Do you have a lot of users doing "subscriptions" to the calendar collection itself? I know we have been meaning to look into improving the performance of calendar collections GETs - however strictly speaking that is not an "official" part of the spec though many CalDAV servers do support that capability.
Two options we have for improving performance are to cache the rolled up calendar data on disk, and/or cache in memcached. If we are really smart we could include an index with that so that we could do partial updates to the cached data as individual calendar resources change within the collection itself - but that would be more complicated.
A key question here is what are the usage patterns for these calendars. Are they updated frequently? If so, how often? How large are they? How many subscribers are likely? Why not just use CalDAV which allows for more efficient partial updates...
As far as I can see the CTag is necessary because an ETag on a collection is not required by WebDAV to change when a member changes content.
Correct - ETags on collections are somewhat vague.
However... with the current calendarserver behavior returning rolled up iCalendar when doing a GET it seems that the Etag must change due to RFC4917 9,4 and RFC2616 13.3.4 (ETag must change when GET value changes).
Correct.
Also, it seems like this is enforced by CalendarServer storing the CTag in an attribute of the calendar collection - which in turn make Twisted update the ETag based on the modification time of the inode.
A nice side-effect!
So, am I right in concluding that CTag and ETag on a calendar collection will currently always be in sync. - partly because of the implementation detail of the on-disk storage that ctag is in an extended attribute. - and partly because it's an implicit requirement when GET on a calendar-collection returnes rolled up iCalendar
That is certainly true right now. To be more robust, what we might want to consider is explicitly having the etag value be the ctag. That way if we ever use a different type of property store (not xattrs) it will still work.
-- Cyrus Daboo _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
