Hi Folks, >> In the given case, don't we just need to run this on each calendar >> event in the collection we're given? i.e. adding a "pregeneration" >> callback API, and compiling a query, seem overly complex to me. (Of >> course, there are plenty of other use cases for FilteredCollections). > > This goal came from the recurrence spec. If you guys want to call > getOccurrences before executing the query, that's less work for me.
The reason I think occurrence generation needs to happen in the query is to avoid situations where a parcel author decides to create a cool new Kind based in part on CalendarEventMixin, using queries relating to startTime and endTime, not knowing their code needs to explicitly call getOccurrencesBetween because they weren't really thinking about recurrence. I have to admit, I'm having trouble sketching such a use case out further right now. I have this vague uneasiness about non-OSAF parcel developers having to think about recurrence, perhaps 3rd party developers basing Kinds on CalendarEvents really isn't going to happen. I really don't know, what do other folks think? In some ways this is a hold over from my hopes for occurrences-as-proxies instead of occurrences-as-items. My implementation plans were to just call getOccurrencesBetween in the Calendar view and reminder code so we didn't have to wait for Ted to work on this. Maybe we can wait forever :) Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
