[Dev] Re: Recurrence discussion

[Grant Baillie]

Hey, Alec

I have a few comments (below) about this stuff. I should preface them  
by saying that I'm not trying to make anyone revisit an engineering  
decision (with all the tradeoffs that involves). In fact, the chosen  
path conforms well to the XP rule of not implementing stuff too  
early: cf <http://www.extremeprogramming.org/rules/early.html>.

I suppose, then, this is a "here are some things I think we'll  
eventually run into down the road" kind of message :).


(1) The chosen solution persists redundant information. In almost  
every case where I've seen this done, there arise problems when some  
of the redundant information changes unexpectedly and things get out  
of sync.

(2) There are other cases where data doesn't always fit so well into  
the "persist everything" model. One example is supporting an "online"  
IMAP mode à la RFC 1733 (not that this particular case is on the  
radar for Chandler anytime soon).

(3) We are choosing an implementation that doesn't scale well. If a  
user (possibly through a typo, or maybe out of idle curiosity as to  
what day of the his/her 40th birthday will be) jumps to the year  
2025, are we going to stuff 20 years' worth of recurring events into  
the repository?

(4) Maybe I'm nitpicking here, but the mention of views generating  
events seems to me to be mixing different layers.


--Grant

On May 9, 2005, at 4:02 PM, Alec Flett wrote:

> I don't want to venture too far down into this discussion again,  
> but the crux of the issue is that chandler is a different beast  
> than typical calendar apps - events are objects in a larger system,  
> and there are multiple ways of viewing those events, not just the  
> Calendar. As Chandler grows and is extended by other developers,  
> the number of views will only increase... the summary table and the  
> detail view are just two examples of views onto items.
>
> This means a view cannot dynamically generate these "virtual"  
> events very easily (Because we don't always control the view) and  
> even if one very smart view (i.e. the calendar view) could generate  
> them, then handing them off to another view (i.e. the detail view)  
> leads to more headaches..
>
> We did explore the idea of these "virtual events" and even  
> discussed having the repository somehow generate them magically  
> through queries, but it really seemed like the problem got nastier  
> as we delved into the details of it - we needed proxy events that  
> shadowed real events, and all sort of other complexities.
>
> In the end, it looks like we've decided to go with a model where we  
> generate "concrete" events some time into the future (right now  
> we're talking about maybe 1 year, but that is a minor detail) and  
> letting the rest of chandler deal with them as if they were just  
> normal items. This greatly simplifies much of the implementation,  
> and focuses the "recurrence" part of the problem on only the code &  
> UI that deals with recurrence, rather than burdening the whole  
> system with some large abstraction that would only be helpful to  
> calendar.
>
> Alec
>
> Lisa Dusseault wrote:
>
>
>> 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
>>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>