[Cosmo] Re: indexing all components in a calendar resource?

Cyrus Daboo cyrus+lists.cosmo at daboo.name
Tue Feb 14 06:38:28 PST 2006


Hi Brian,

--On February 13, 2006 8:14:19 PM -0800 Brian Moseley 
<bcm at osafoundation.org> wrote:

>> I myself am confused how you'd query VCALENDAR properties with
>> CalDAV.  A client can't store a whole VCALENDAR as a single CalDAV
>> resource, that would be against several of the rules of CalDAV.
>> Instead, since dealing with entire calendars isn't part of CalDAV but
>> instead a non-standard way of handling what Apple's iCal does, I
>> would say that a server would explode out the events into individual
>> resources and throw away whatever information was leftover that
>> wasn't needed for interpreting those events.
>
> even within a single caldav resource, it seems to me that the only
> interesting data are the event components themselves (and later
> freebusys, todos and journals), not the properties of the wrapping
> vcalendar or any of the supporting vtimezones. sure those things are
> potentially needed by the server to process the event (expanding time
> ranges is a good example), but i don't see why any client would ever
> need to query against any of that data.

It is hard to see a use case for those. However, lets say the VERSION gets 
bumped at some point in the future - a client may well want to exclude 
components of an older/newer type. As to VTIMEZONE - at some point people 
may want to use a CalDAV server as a VTIMEZONE store for standardized 
timezones in which case a query on the timezone name (at a minimum) would 
be required. But of course there is no immediate need to do that right now.

>> Are we missing some implication of REPORTs?
>
> i wonder if the specification isn't just too loose in regard to what
> components within a resource can be queried against. but maybe i just
> haven't considered a valid use case ;)
>
> anyway, we can drastically cut down the amount of data we have to
> store and index if we are able to limit queries to just the
> "important" components.

The next CalDAV draft will allow servers to reject queries against 
non-standard components and properties etc (i.e. X- ones). So you can 
certainly choose not to index those and instead return the relevant error 
precondition code (Lisa, Bernard and I were discussing that just 
yesterday). You do still need to handle non-standard items in the returned 
calendar-data though, so you can't simply discard those.

As to indexing all the rest - well you do have to allow queries against 
anything, so one way or another you have to do that, but whether that is 
done by indexing everything, or only select components/properties is really 
up to you. If a client really does want to query some 'obscure' property 
(e.g. PRODID) I don't see why the server has to be as fast on that as all 
the rest. Note that many servers use a database backend rather than 
straight indexing, and often they choose to only have separate columns for 
select properties, putting all the rest in a 'catch-all'. So with those, 
queries against select properties will be fast, against others will be slow.

-- 
Cyrus Daboo




More information about the Cosmo mailing list