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

Lisa Dusseault lisa at osafoundation.org
Mon Feb 13 18:40:13 PST 2006


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.

Are we missing some implication of REPORTs?

lisa

On Feb 13, 2006, at 6:28 PM, Cyrus Daboo wrote:

> Hi Brian,
>
> --On February 13, 2006 5:55:00 PM -0800 Brian Moseley  
> <bcm at osafoundation.org> wrote:
>
>> cyrus, i notice that the TextCalendarTextFilter indexes all of the
>> properties and parameters of all components in the calendar object,
>> including the outermost vcalendar as well as any contained timezones.
>> is that really what you meant to do?
>>
>> seems to me that only the properties and parameters of the actual
>> events need be indexed for report queries, but i might not know what
>> i'm talking about ;)
>
> The spec itself is not just limited to events - any iCal item, no  
> matter at what level or what type, can potentially be queried for.  
> Of course in reality how many clients will actually want to query  
> the PRODID or VERSION properties at the top-level. Chances are not  
> many, but if they were to, the server would have to do the query  
> one way or another to be compliant. If you wanted to reduce the  
> size of the index you could just do events - but then you would  
> have to fall back to inspecting the actual iCal data for queries on  
> anything else.
>
> BTW Just thinking about this: one thing you certainly do want to do  
> is not index the value of an ATTACH property which could be quite  
> large and will not contain anything worthy of a query (its usually  
> base 64 encoded). I guess that's one I should have definitely left  
> out.
>
> -- 
> Cyrus Daboo
>
> _______________________________________________
> Cosmo mailing list
> Cosmo at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo




More information about the Cosmo mailing list