[Cosmo] Exception When PUTting Event, Slowness when PUTing recurring event

[Cyrus Daboo]

Hi Bobby,

--On December 21, 2005 1:02:20 PM -0500 Bobby Rullo <br at osafoundation.org> 
wrote:

>> How to resolve this: the key thing is to try to limit the maximum
>> number of cached instances to say 1000, and generate an error on
>> PUT if the recurrence set is larger than that. When I added
>> 'COUNT=1000' to the RRULE in Bobby's example, it did get properly
>> stored and indexed and it took about 5 seconds to get the response.
>> No out of memory errors etc. A time-range report did return the
>> component as expected. Same went for the src/test/resources/dav/
>> caldav/event3.ics example that Brian was using.
>>
>
> Shouldn't Cosmo be able to handle unbounded recurrences (they are  legal
> in icalendar and CalDAV rfc's right?), or do you intend this as  a
> temporary fix?

Whilst iCalendar supports unbounded recurrences, actually using them in a 
practical sense can be limited. In particular, iTIP defines a response code 
so that attendees can indicate that they are only prepared to handle up to 
a certain amount of recurrences in a recurrence set. So there is a 
reasonable expectation that a consumer of iCal data will reject components 
that generate too much.

What Cosmo should do is accept any valid recurrence set on PUT, but only 
expand up to allowable server limits. The index for that component should 
be marked with the applied limit if one was applied. Then, when the report 
runs, if the time-range request is outside of the server limit, the proper 
DAV:number-of-matches-within-limits code can be returned.

Doing something like that will require changes to ical4j to allow expansion 
to be limited to a maximum count, a change in the indexer to include in the 
time-range field an indicator that the limit was or was not reached, and a 
change to the time-range term comparator to catch the limit being exceeded.

-- 
Cyrus Daboo