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

Helge Heß me at helgehess.eu
Wed Jul 1 10:39:40 PDT 2009


On 01.07.2009, at 16:58, Cyrus Daboo wrote:
>> 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.

We certainly don't and I'm still not sure why you assume that clients  
will? At least Evolution and Kontact use iCalendar as their internal  
data format and AFAIK preserve anything thrown at them. (would need  
more testing of course, would be good to do that at CalConnect)

>> (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.

Hm, OK :-)

> 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.

Yes, parsing the V data is quite expensive. I'm just assuming that  
recurring events are the minority (<20%?) in a bigger personal calendar?

>> 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.

I agree. Because of this I think I would actually keep the freebusy  
data in a separate table/store and update that asynchronously. But  
anyways ;-)



OK. This is getting a bit off-topic. I guess I need to ask the user  
whether they are OK with a 400 COUNT coming up in Outlook. At least  
our QA guy marked plugin RRULE generation as broken because his  
selection wasn't preserved ;-)

I wonder whether it would be better if the server would reject RRULEs  
it can't store with a proper error code. (which tells the client that  
the user must specify a smaller COUNT, smaller UNTIL, etc - we could  
show that to the user in Outlook).

Thanks,
   Helge
-- 
Helge Hess
http://zideone.com/


More information about the calendarserver-dev mailing list