(Filing a bug to hold the eventual patch) I'd like to do an oeIICal implementation that uses mozStorage as the back-end implementation, instead of libical. Todo list: * make sure we can continue to import ics into and export ics from the mozStorage db * figure out how to integrate recurrence calculation -- which parts can be reused from libical? I've started work on the actual sql mapping, however I need to do a little research on any current iCalendar SQL mappings (especially the pseudo-SQL used by libical for queries). The goal is to support virtually all operations as direct SQL queries; if we can't do a direct query, we should be able to filter down the number of entires we need to iterate through to a very small set.

One idea: separate A. nonrecurring events & tasks (& someday journals) of a day or less duration (which can be indexed by date) B. other material, longer than a day or recurring or undated tasks For many people who have large calendars (thousands of entries), I suspect 'A' makes up the bulk of the entries (scheduling one-time appointments & tasks). These entries can be indexed by start or due date. The events in an index sorted by date must have duration limit so that you can limit how far back in time to look for events that might overlap a range. A day seems like a natural limit that would be effective. One thing that currently slows down calendar is that it treats all events as potentially recurring, so whenever it looks for events in range, it scans ALL events and looks for a recurrence in the range. Separating the large number of one-day events from the recurring and multi-day events means it only has to scan the smaller number of recurring and multi-day events. (Currently the events are kept as a linked list, so this scan grows with the size of the calendar. It first scans to find the position in the list it last returned, and recent events are at the end of the list, so a computing events for a view like month view takes O(nRanges * nEventsPerRange * nEventsInCalendar). I'm thinking of GetEventsForRange http://lxr.mozilla.org/mozilla/source/calendar/libxpical/oeICalImpl.cpp#1477 GetEventsForRange calls GetNextEvent for each event found. GetNextEvent http://lxr.mozilla.org/mozilla/source/calendar/libxpical/oeICalImpl.cpp#1596 GetNextEvent scans the linked list of events from the beginning for every call. On each event it calls GetNextRecurrence. )

(In reply to comment #1) > One idea: separate > A. nonrecurring events & tasks (& someday journals) of a day or less > duration (which can be indexed by date) > B. other material, longer than a day or recurring or undated tasks > > For many people who have large calendars (thousands of entries), I suspect 'A' > makes up the bulk of the entries (scheduling one-time appointments & tasks). > These entries can be indexed by start or due date. Yep, that was my thinking as well. My plan currently is similar to what you describe -- basically, when figuring out events during a range, we need to look at: 1. Non-recurring events with appropriate start/end dates 2. Recurring events for which the current range falls within the event's first/last dates 3. Recurring events for which there is no end date, and the start date is before the start of the range We'd end up with two SQL queries, one for #1 and one for #2 & #3; the query for #2/#3 can also make use of a custom-written function to actually calculate the recurrence, such that everything takes place within the sql engine for speed.

the idea in bug 157169 comment 4 might be interesting to think about.

Note on http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/calendar/base/public/calIItemBase.idl&rev=1.1&root=/cvsroot I think importing RFC2445 iCalendar files is important for interoperability, so the interface should be compatible with rfc2445 recurrence rules. The current calendar event recurrence UI only implements a subset of recurrence rules that libical implements. A better introduction to what is possible is to see the examples in rfc2445sec4.8.5.4 and the grammar in rfc2445sec4.3.10. http://www.geocities.com/gekacheka/rfc/rfc2445.html#s4.8.5.4 http://www.geocities.com/gekacheka/rfc/rfc2445.html#s4.3.10 1. A recurrence rule should probably be a separate object. There will be times when an event needs more than one. (To start simple, maybe just provide each as a string?) Example: an event that occurs on 4 july (RRule1) when 4 july falls on Mon-Fri, occurs on 3 July when 3 july falls on a Friday (RRule2), and occurs on 5 july when 5 july falls on a Monday (RRule3). Example: an event (bill due) that occurs on 1st of month when 1st falls on Mon-Fri (RRule1), except for Jan1 (ERule1), occurs on 2nd when 2nd falls on Monday (RRule2), and occurs on 3rd when 3rd falls on Monday (RRule3)... 2. Will need recurrence dates (RDATE) list as well as exception dates (EDATE) list. (Some holidays are determined by the phase of the moon and not by gregorian calendar dates, so cannot be given by an RRule.) 3. Dates are optional, at least for tasks. There should be some way to set a date or clear a date, and to test whether a date has been set. Since the date attributes are readonly, will these be methods on calIDateTime? (isSet is missing in oeICalDate, which has caused problems.)

(In reply to comment #4) > The current calendar event recurrence UI only implements a subset of recurrence > rules that libical implements. I'm don't really agree; the rfc2445 RECUR/RRULE is ridiculously overspecified -- I'd rather support the most common usage and a bit more, rather than being able to represent recurring events on Mars (as someone recently put it) and/or generate a set of RRULEs to play Towers of Hanoi in a calendar app that implements the full spec. The interfaces can (and will) evolve; they're not even remotely close to frozen. But for recurrence, I'd wait until we see what the CALSIFY group does with recurrence before making any decisions. > 3. Dates are optional, at least for tasks. There should be some way to set a > date or clear a date, and to test whether a date has been set. Since the date > attributes are readonly, will these be methods on calIDateTime? (isSet is > missing in oeICalDate, which has caused problems.) Mm, you're right; the dates in calITodo should not be readonly (null is valid). I've fixed that here, will check in soon.

vlad: I think gekacheka makes a good point about interoperability here. Even if we don't want to expose all the obtuseness of RRULE in the UI, it's important to be able to do import -> modify -> export of a calendar without losing any data.

This is a first cut patch at this; the core bits work, but it's more of a proof of concept than a working impl -- the real impl will come when we move over to the newfangled calendar interfaces.

vlad, is this still an issue now that libxpical is deprecated and obsolete? Can we close this bug?

Yeah, WONTFIX.

Mass move of libxpical bugs to the Internal Components, per ctalbert.

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!