[Dev] implementing recurrence in the repository

[Alec Flett]

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