Jeffrey Harris wrote:
- We can't represent indefinitely recurring events in the repository,I think this is actually the hardest problem we're facing in chandler, probably due for its own thread.
currently the only way to create a recurring event is to import it from
iCalendar, and then only the first 10 events are put in the repository
to avoid infinite loops
I second your motion to use ICU date/time stuff, but knowing nothing more about it I'm hoping Nick can at least give us a little information about the bindings -i.e. the maturity of the the bindings today vs. mx.DateTime. Nick, do you have any sort of page describing your progress, or work we can download and maybe contribute to right now?
I have no desire for us to write our own recurrence library, so I also like the use of dateutil.rrule. Let's just agree that's what we're using sans any massive technical hurdles. I've looked around and I can't find any info on rrule though - is there a web page out there for it? I guess I'm curious what requirements it has, and what the interface is like...
I think we have two options. The decision is probably a technical one, and Jeffrey I think you're the expert here..
- we can contribute back support for ICU to dateutil.rrule- if rrule isn't heavily bound to datetime (though I suspect it is...)
- create our own wrapper or glue code around rrule so that we can easily translate the two.
I suspect we'll have to do the latter since we're also bound up by mx.DateTime constraints at the moment.
In any case, I want to be able to use dateutil.rrule or chandler.rrule as if it is the real rrule, but dealing with ICU dates. Same API, etc, so that if rrule ever adds support for ICU, we can keep getting and using updates.
If ICU datetime is really where we want to go, we should probably at least discuss and document a migration path for all of chandler, if only to help us understand the reasons and scope of the migration. I don't think it has to be a single monotonic conversion though.
Alec _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
