[Dev] Re: Recurrance discussion

[Alec Flett]

I haven't been replying much to the e-mail thread about this, but I'm 
glad we're all on the same page with respect to repeating events!

I'm not too concerned about the mechanism for updating infinite 
occurence items way off in the future, and the exact policy for when 
they get updated. Those are low priority details that we can flush out 
in the spec.

In the mean time, I think its time to start flushing out data types so 
we can start some initial sprint implementation

What I imagine is that a recurrence "master" event (basically building 
on the existing EventMixin type) that has a bidirectional attribute 
pointing to its "child" events, as well as an attribute describing the 
rule.. but I don't know what type that rule is - is it a string? is it a 
data structure of some kind?

We talked about it being a data type in the repository, but after 
futzing with ColorType last week, I'd really prefer to keep complex data 
types out of the repository type system.. but I'd like to hear the 
reasons for the data type in terms of how we'd really use it. Maybe it 
would make querying easier?

For example, we'll need a way to extract certain types of information 
from the rule, including the basics for display in the detail view (i.e. 
"repeats every week") as well as the exclusions/exceptions/etc.

I'd like to propose that one way we can get started is for Jeffrey, who 
knows the iCalendar data the best, to come up with a Kind to represent 
the rule.. does that seem fair? Then we can at least talk about the rest 
of the recurrence implementation (i.e. what queries look like, how we'd 
extract data to display in the detail view, and so forth)

Alec

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?
>
>  
>
Yeah, I don't think the timing/mechanism for updating these events is 
orthogonal to the actual

>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
>  
>