[Dev] Re: Recurrance discussion
jeffrey at skyhouseconsulting.com
Mon May 9 16:59:23 PDT 2005
> 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
What I've proposed is that events have
A) a bidirectional link to an item of kind RecurrenceModificationSet,
which keeps an ordered list of modifications, and maintains links to the
set of magically generated occurrences
B) an rruleset attribute, of type RRuleSet (I've had coding this type on
my list for a few weeks, pinning down the spec has taken priority for
This approach allows us to avoid having different kinds for master
events and occurrences, which seemed attractive to me.
> 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?
RRuleSets should have Python class dateutil.rrule.rruleset. I'm hoping
mortal developers won't need to know anything about how those objects
are persisted. I suppose we could persist iCalendar RRULE strings, but
it seems cleaner to persist an analog of rruleset's data structure.
> 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.
Exclusions will live in rruleset's exrule attribute. Exceptions will be
modifications that live in the RecurrenceModificationSet. Walking over
these and accumulating the relevant details won't be nothing, but it
should be doable. Methods for gathering such details should be part of
CalendarEvent items' python representation, specifying these methods in
greater detail does seem like the next step.
> 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)
Yup, this sounds good. One question, do folks care whether RRuleSet is
a Kind or a Type? I think rrulesets are values, not entities, seems
like I'm unlikely to ever need a bidirectional link to the "every
Tuesday at 9AM" rule. Making RRuleSet a type has the advantage that
it's python representation doesn't need to know anything about Chandler,
then it can just be a dateutil.rrule.rruleset. I guess that's not
terribly important, subclassing is no big deal, but using classes with
no Chandler dependencies seems cleaner to me.
More information about the Dev