Hi Lee, Thanks for commenting.
> Two minor topics are not explicitly addressed in your description of > recurring events. > > 1. Should historical occurrances of recurring events be maintained > as unique history elements, or should they be treated as a set of > 'history items' for the recurring item? My preference is for the > former, that once an event 'happens', it is an explicit item, > regardless of the original source, fully capable of having notes and > other items attached to it. Generated occurrences will come into being if a query is issued relating to that time period (for instance, if the user moves their calendar view to that month), independent of whether that time period is in the past or future. > 2. Occurrance patterns which are not 'daily, weekly, monthly' > should probably also be supported. Examples include (weekly, choice > of up to seven days for multiple occurrances in a week), (monthly, by > day of month (1st Sunday), day of week (3rd Thursday)). or other > period with the possibility of multiple items within the occurrance > period. Our content model will allow for arbitrarily complex rrules (and combinations of rrules). For 0.6, we won't implement UI to allow the user to create complex rules from within Chandler (we're trying to walk before running), but see the Importing a calendar section of the spec: If the [imported] event was created using a more complex recurrence algorithm than those available in Chandler, the Custom option will be selected and a some static text describing the details of the recurrence rule will be displayed below the "occurs" drop down field. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
