[Dev] implementing recurrence in the repository

[Phillip J. Eby]

At 08:07 AM 3/28/05 -0800, Alec Flett wrote:
>- 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.

Or conversely, to make it clear that there is only one event, and that it's 
simply shown various times on the calendar (as in Ecco).


>- 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.


A relatively simple solution is to simply record start and end dates for 
the recurrence period, and query for items whose range overlaps the display 
period.  The recurrence period would then provide a way to iterate over its 
occurrences within a given display period.  (And display period here can 
also be interpreted as "alarm period"; i.e., alarms would do the same thing 
to find out about occurrences.)

IOW, Events are not what gets shown on the calendar; Occurrences are.  But 
Occurences are not necessarily persistent objects unto themselves, just 
values that get displayed.

Of course, the flip side to all this is that direct manipulation of an 
occurrence is potentially ambiguous as to whether the change should apply 
to all occurrences of that event, and leads to a more complex specification 
of the recurrences.  Do we have a spec for what direct manipulation does 
for recurrences?