[Cosmo] Re: indexing all components in a calendar resource?
cyrus+lists.cosmo at daboo.name
Tue Feb 14 06:38:28 PST 2006
--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.
More information about the Cosmo