[Dev] implementing recurrence in the repository

[Lisa Dusseault]

A more common way of implementing this (what I saw in MS Outlook's 
implementation, as well as how the Oracle and Mulberry stuff is 
explained and what the iCalendar format is optimized for) is to store 
only the recurrence event "master" and exceptions.  So if I schedule a 
weekly meeting where every instance is the same, that's just one stored 
item.  However if I change the subject of one instance, or reschedule 
that instance to a different day or time, or invite a new person to 
that instance, that instance becomes an exception -- another stored 
item with links back to the recurrence master.

This model makes it much easier for us to export data into a concise 
iCalendar file, or, for that matter, to generate invitations using 
iCalendar.  We don't have to weed out any generated events from the 
exported data.

Looking at a week's events might not be very fast when you have to look 
at every recurrence master and see if it has an instance that week, but 
that's what caches are for.  Caching achieves much the same effect as 
generating n instances as you describe below, but it's more 
generalizable and cleans up better.  It allows us to see recurring 
events for a week's period arbitrarily far into the future without 
special logic -- the virtual instances get generated and cached and 
then if the user rarely views that future week, those things time out 
of the cache.

What might be special for us is when we link an instance of a recurring 
event to some other item -- e.g. if the user generates an email that 
should be linked to "this week's status meeting".  I think we should 
model those as exceptions, as well.  Basically, "this week's status 
meeting" becomes an exceptional instance of the recurring meeting by 
virtue of having emails linked to it that other instances don't have 
linked to it.  In fact, when we export such a meeting, we might even 
preserve the linking information by storing the email IDs in the 
iCalendar data.

Lisa

On Mar 28, 2005, at 8:07 AM, Alec Flett wrote:

> Jeffrey,
> Per my last post, we need to talk separately about how to actually 
> store & represent recurring items in the repository.
>
> The basic problem we have is that the repository doesn't exactly have 
> infinite storage, or representation for an infinite set of items.. and 
> we probably don't want to deal with them even if it could, like you 
> said, to avoid infinite loops.
>
> So working under that assumption, I think what we want to do is create 
> a "recurrence event" Kind, and link calendar events back to that 
> kind.. That kind isn't actually a CalendarEvent or anything, but a 
> distinctly new type that represents the recurrence (perhaps just as a 
> vCalendar recurrence string?) and links to the dependent 
> CalendarEvents. That part is easy...
>
> The real problem comes in when determining how and when to generate 
> the concrete events that link to this object, and how other parts of 
> the system are aware of both concrete and not-yet-generated events. 
> Your method for starting with the first 10 concrete dates is a good 
> start. A few ideas I had on the plane back from PyCon:
> - generating n events, such as 10 events, is probably not quite what 
> the user is expecting because I think the user thinks in date ranges, 
> not event counts. i.e. if we're generating 10 events at a time and a 
> user has something recurring on M/W/F, they're going to see 3 weeks of 
> Mon/Wed/Fri events generated, plus a Monday. Perhaps what we really 
> want is to keep generating events "n weeks in advance" or something? 
> The "n weeks in advance" limit could be a system wide default, but 
> could also be stored on the recurrence object I described above..
> - we'll need a way to keep generating events as time moves forward. I 
> think a wakeupcaller that fires at startup and then every hour/day/etc 
> could ensure that the minimum number/range of concrete dates has been 
> generated in advance. That shouldn't be too hard
> - ideally the user should never have to think about the whole notion 
> of concrete and not-concrete events.. so we need to do our best to 
> make it appear like the concrete events really do exist.
> - free/busy stuff could automatically work around recurrence events, 
> even if the concrete events haven't been generated yet. i.e. if I'm 
> looking ahead 2 months for free time in my calendar, we don't have to 
> generate the concrete events to find times that don't conflict with 
> recurring times (whew, that's a mouthful!)
> - The calendar view itself could act as though some of the concrete 
> dates have actually been generated... i.e. if I'm looking at a week 2 
> months from now, the calendar view could display events even though 
> they haven't actually been generated yet.
> - obviously CalDAV is a big issue here.. as I understand it, CalDAV 
> stores repeating events as a single object.. so if anything we have to 
> be careful that we don't try to send our concrete events off to CalDAV
>
> These last three points call for a mechanism to get future event 
> information without generating Items in the repository. That also begs 
> the question, why generate any concrete events at all if we're already 
> providing this mechanism for viewing non-concrete events? Something to 
> think about.
>
> Alec
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev