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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
