[CalendarServer-dev] CTag/ETag on calendar collections
cdaboo at apple.com
Tue Jan 5 07:41:23 PST 2010
--On January 5, 2010 3:21:34 PM +0100 Peter Mogensen <apm at 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
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).
> 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.
More information about the calendarserver-dev