[Dev] Re: Recurrance discussion

[Lisa Dusseault]

I pinged a couple iCalendar implementors about how they do this today.
  - One of them stores only recurrence masters and exceptions in their 
repository.  When the client needs to display a time period, it asks 
for a list of events in that time period, and the model logic 
constructs objects for recurrence instances as well as for regular 
events, and hands that list off.  Changes may be made to instances or 
non-recurring events, and the model logic handles that either way.  I 
believe this is the pure "virtual event" model that Jeffrey originally 
proposed.
  - The other implementation *expands every recurring item into 
instances for storage* -- expanding all instances and until 2038!  
Apparently the world ends on 2038.  On the bright side, with no 
birthdays after 2038 we won't be getting any older.

Lisa

On May 9, 2005, at 12:55 PM, Jeffrey Harris wrote:

> Hi Bryan,
>
> I'm ready to really and truly drop the idea of transient 
> items/proxying.
>   Hooray, if only I were less stubborn, I would've given in a week ago 
> :)
>
> I like the idea of periodically updating infinite occurrence items one
> year in advance, perhaps scheduled to happen daily at midnight (for
> those who leave their apps running 24/7).  We'll also need some
> mechanism for dealing with the user browsing their calendar ahead a
> year, do you have an idea of where in Chandler that should be dealt 
> with?
>
> As Bryan and Alec and I discussed at one point, the algorithm probably
> shouldn't be exactly one year in advance, pathological cases like
> biannual events with 15 month reminders need to be dealt with, a more
> detailed description would be one year + reminder delta in advance for
> each recurring event.
>
> Sincerely,
> Jeffrey
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev