Hi Alec, [snip]
> 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.. 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 me, though) This approach allows us to avoid having different kinds for master events and occurrences, which seemed attractive to me. [snip] > 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. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
