[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:
>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.
>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 
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.

More information about the Dev mailing list