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

[Lisa Dusseault]

Cyrus, I still don't understand how VERSION would even get uploaded  
to a VCALENDAR component in a CalDAV server.  Are you saying that a  
client would PUT a VCALENDAR component resource to be a child of a  
calendar collection?

Lisa

On Feb 14, 2006, at 6:38 AM, Cyrus Daboo wrote:

> 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
>
> _______________________________________________
> Cosmo mailing list
> Cosmo at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo