Hi Helge,
--On July 1, 2009 4:44:24 PM +0200 Helge Heß <m...@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
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
