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.
Darn.
> 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?
The reason for the heuristic is just that it seems weird to look at next year's calendar and have nothing on it. If performance were not an issue, the "best" thing to do would obviously be to generate 100 or 1000 years worth of recurrences, because users probably won't care much about ocurrences that follow their death. :)
So, the only reason to do *less* than a lifetime's worth is for performance, and the performance is presumably linear in the number of occurrences generated. Thus, if we say, "you get 500 recurrences for infinite events", then a yearly recurrence gets you 500 years, and a daily recurrence gets about a year and a half.
It would be interesting to know, however, just how often infinite events get used. There are only so many weekly meetings and daily schedule items that you're going to have. And it would also be good to know the performance impact of having N occurrences.
Right now, there are two kinds of performance hits: the time to add the occurrences, and the impact of occurrences on queries. The former only has to be paid for once, but the latter could be a gift that keeps on giving. :) In order to avoid it, the application is going to have to make smart use of indexes, or else the query system is going to have to be smart enough to take advantage of them in the case of e.g. finding items within a date range.
I'm partial to just generating new occurrences daily at midnight or first start up. It seems more deterministic to me.
That's an implementation detail that I sort of assumed. I meant that logically there's an alarm, I didn't really mean to imply that they'd actually be processed individually, as a batch would be more efficient. Sorry for being so abstract.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
