[Dev] Re: Recurrance discussion
Phillip J. Eby
pje at telecommunity.com
Wed May 11 12:18:43 PDT 2005
At 01:53 PM 5/11/2005 -0500, Jeffrey Harris wrote:
> > 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.
>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?
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
>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.
More information about the Dev