[CalendarServer-dev] Unbound RRULE rewritten to COUNT=400

[Cyrus Daboo]

Hi Helge,

--On July 1, 2009 4:44:24 PM +0200 Helge Heß <me at helgehess.eu> wrote:

>> We deliberately truncate unbounded RRULEs that would generate too
>> many instances in our index for performance reasons.
>
> OK.
>
> I still wonder if it would be better for the usability if we re-translate
> the 400 to unbound. Hm. Would it make sense to add a property which
> signals the truncation?

I am not sure whether a X- parameter on the RRULE would be good or not. We 
now that clients are likely to throw away X- parameters.

> (BTW: most clients will probably never use server side RRULE expansion? A
> webclient is the only thing which might make use of those REPORTs, hence
> the indices?)

Actually the server uses the indices for free-busy lookups and for room 
auto-accept processing.

>> At some point we may also revise our indexing to remove the
>> performance issue at which point truncation may not be needed - but
>> for now it is better to do it.
>
>
> Can't you just keep 'small' events in the index and evaluate others in
> memory? I think thats what I originally did in SOGo.

As noted above we really want free busy lookups to be super fast as users 
will expect that to be done in "real-time". So indexing the time periods 
for each event index allows us to quickly find events that overlap a given 
period.

It turns out that right now when we find those events we do go and 
read/parse them to extract information to determine what type of busy-time 
they represent (free, busy, busy-tentative etc). But we have found that 
users tend to do lots of free busy queries and even those read operations 
are slowing things down more than we would like, so we are working on 
putting enough information into the index that we can avoid having to 
read/parse the calendar data on disk.

> This DAViCal thing is also quite interesting:
>
> http://repo.or.cz/w/davical.git?a=blob;f=dba/rrule_functions.sql;hb=HEAD

Hrmm - looks like a stored function in the DB that does recurrence 
expansion. I still think that fully caching the instance time-ranges is 
better - free busy queries need to be done fast.

-- 
Cyrus Daboo