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