RecurringEvents
**Labels:**Phase-Design
Modeling, Controlling, Viewing, and Editing Recurring Events
This file contains notes and ideas for implementing recurring events in Calagator
We are focusing on the iCalendar specification for recurring events because (1) it's complete, and (2) popular calendar systems (Google Calendar, Upcoming, Outlook) use it.
iCal specs for recurring events are here: http://tools.ietf.org/html/rfc2445\#section-4.8.5
The iCal spec is rich, but popular calendars seems to implement only part of it: RRULE and EXDATE
RRULE http://tools.ietf.org/html/rfc2445\#section-4.8.5.4 is a rule for when the event should recur. The iCal spec allows multiple RRULEs for an event, but Google Calendar seems to generate only one.
EXDATE http://tools.ietf.org/html/rfc2445\#section-4.8.5.1 is a list of date/time exceptions. Example:
EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
You cannot create exceptions at the time that you create a recurring event in Google Calendar. Instead, you create exceptions by editing one of the occurrences. Google has a delete option with these choices: delete this occurrence, delete all future occurrences, delete all occurrences.
Vpim turns out to have so many problems that it is not practically usable for recurring events. For instance Vpim does not import EXDATE properties, creates an RRULE when none exists, does not exposes the details of RRULE objects.
Fixing Vpim would be so difficult that we decided to first explore the possibility of finding and using another library such as: lib iCalendar, library used by Mozilla for Thunderbird and Sunbird/Lightning, Darwin, something newer available in Ruby.
In addition to supporting EXDATE and RRULE, it's desirable for the library to support event locations and tags.
VObject is a Python package for parsing and generating vCard and vCalendar files. We might be able to port this Ruby.
the Runt Ruby Gem - an implementation of select temporal patterns. This is a possible format for Calagator's internal representation of recurrence.
- Rails code for recurring event generator Uses Runt. (Although this blog post says "recursive" generator, it probably should be "recurring").
Recurring events should have a master event plus instances. Generate instances only for the next three months, and mark each as tentative. See Tentative events below. A periodic task will later generate later instances (also marked as tentative), so that Calagator always shows 3 months' worth of instances.
Master should include
- Rules needed to generate instances. This should include start date, end date and/or count, RRULE, EXDATE
- Perhaps also keep the date of (or id of?) last instance generated
- How to deal with a deleted instance? One possibility is simply adding it to EXDATE.
Some ideas are at
This has sufficient functionality for our purposes _except_ that it lacks an end point. The form should ask the user for (a) an end date EXOR (b) a total number of occurences.
- Keep ID of master
- Include field that marks the instance as tentative, confirmed (or canceled?)
When a recurring event is first created, it should create three months of instances, and mark each one as tentative.
A task that is run periodically creates any instances that occur after the first 3 months.
If the periodic task is run daily it will create 1 instance at most.
For each master event that has not expired (this is easy to tell if there's an end date, but harder if there is a set number of instances; perhaps we want an expired field), calculate the date of the instance that is after the last instance previously created, if that date is within 3 months and is not an exception (EXDATE), create an instance with that date
= These are automatically generated recurrences of imported event
Need an extra field to indicate that this is tentative. Possibly have different display for tentative events that were generated from a recurring event without a recently confirmed instance.
Possibly display event in different color. Possibly add extra line saying that event is tentative/automatically generated.
Add information that gives user idea how stale date is, such as when master was generated, when an instance was last confirmed.
Should ask whether user is editing just this instance or all recurrences
Need way to confirm that event is indeed occurring (possibly just turn off tentative field); This should be a check box (for the single event).
We need a way to handle this differently from other edits. For instance, we may want to apply an edit (e.g., change of location) to all future instances, but we should not allow users to confirm all future instances.
Possibly allow people to confirm the next few events (or events in a a given time period like the next few months).
???
VEVENTs have STATUS property which can be TENTATIVE, CONFIRMED, or CANCELLED. It's not clear how well supported this is. ICS files exported from Google Calendar do set this property. ICS files exported from Upcoming do not include this property.
Gardening tool -- we'll probably want a way to review "stale" events. "Stale" means recurring events that have not had a confirmed event in (period of time to be determined).
Suggestion: Display list of such events with Delete / Confirm / Skip radio buttons for batch updates.
INITIAL REVIEW NEEDED