Hi Phillip, > Strawman proposal 1: implement occurrences as real items, created when > the rule is modified. Require users to *always* include an explicit end > date; i.e., no unbounded recurrences.
[snip] The biggest con for this is that users are very likely to import or share indefinitely recurring events. So I don't think we can avoid indefinite recurrence in 0.6. > Strawman proposal 2: The same as proposal 1, but allow users to not set > an end date. If no end date is supplied, generate a *fixed* number of > repetitions using a heuristic based on the frequency of occurrence. For > example, for annual occurrences you could schedule 10 or 12 years in > advance, while we might limit daily occurrences to a year's worth. This > caps the cost of generating occurrences, but increases complexity by > requiring the heuristic logic, and by requiring an alarm or something of > that sort associated with each recurrence to automatically add one > *more* occurrence each time one is consumed, thereby keeping the > "sliding window" always the same size. Do you see a particular advantage to this approach over generating occurrences 1 year + magnitude of reminder delta in advance? I'm partial to just generating new occurrences daily at midnight or first start up. It seems more deterministic to me. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
