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/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
