[CalendarServer-dev] Unbound RRULE rewritten to COUNT=400
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-
>> 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,
>> 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
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:
> 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
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).
More information about the calendarserver-dev