Overview
Goals and Objectives
The goal of reminders in 0.6 is to provide enough flexibility in the data model for most iCalendar VALARMs to be imported and exported while adding no or very few additional UI and design requirements.
- Sheila Mooney
- Spec owner and contributor
- Jeffrey Harris
- Spec contributor
- Bryan Stearns
- Spec contributor
Background
In 0.5, reminders were modeled as one or zero deltas from the startTime or dueDate of items. Once a reminder fired, it was erased.
While this model is a good proof of concept for reminders, it matches up poorly with the iCalendar equivalent, VALARM. Events in iCalendar can have an arbitrary number of VALARMs, not just one, they can apply to each event in a recurrence set, and they can be set to do different things when they're triggered such as send an email, play a sound, or display a message on screen. VALARMs can be set to repeat periodically after they're first triggered. They can also be defined relative to the end time or the start time of an event.
Chandler may not expose most of these features for reminders, but it's desirable to allow VALARMs to at least have a path to allow import/export without loss of fidelity.
User Interface
When a user creates an event, they will be presented with a drop down box allowing them to select a small number (fewer than 10) of possible deltas before startTime, or None. No additional options will be provided for users in 0.6. Once a reminder fires, it will be rendered as None.
UI behavior for multiple alarms will be rudimentary and confusing in 0.6, and that's OK, because it's an extreme edge case.
If an iCalendar event is imported more than one VALARM, multiple Reminder items will be created. Only the first reminder will be rendered and modifiable by the user. If a user sets a reminder to None, or the first reminder fires, this will shorten the list of reminders and UI will render the next reminder.
Recurrence UI
Occurrences and modifications to recurring items with a reminder will render the first reminder for that occurrence even if it has expired, to allow users to make THISANDFUTURE changes to the reminder delta.
[Jeffrey] This seems necessary, but different from the behavior for non-recurring items. Perhaps we should always render the reminder delta, even if it's expired, now that we're saving expired reminder information.
Architecture
Overview
Instead of having one reminderTime attribute, items which may have reminders should inherit from RemindableMixin, adding reminders and expiredReminders attributes which link to Reminder items. As reminders are fired, their links move from the reminders attribute to the expiredReminders attribute.
Reminder Data Model
RemindableMixin (Kind)
Key attributes:
- reminders - set of Reminder items or None
- expiredReminders - set of Reminder items which have already expired, or None
- reminderBaseTime - time to which reminder.delta should be added to get a reminder's trigger time, generally should be redirected to startTime or dueDate
Instance methods:
- makeReminder(delta) -> convenience method to create a new Reminder item
Reminder (Kind)
Key attributes:
- delta - DateTimeDelta
- relativeTo - aspect of reminderItems to add delta to (defaults to 'reminderBaseTime')
- reminderItems - set of RemindableMixins that have not yet expired or None
- expiredReminderItems - set of RemindableMixins that have expired or None
- nextReminderTime - DateTime, should be set equal to reminderItems.sort()[0] + delta
[Jeffrey] Is nextReminderTime really necessary?
Processing Reminders
When a reminder is fired, the reminded item should be set to expiredReminder. If the firing reminder is for a recurring item, createNextOccurrence() should be called on the item. nextReminderTime should be set. If nextReminderTime is in the past, fire it, repeat.
[Jeffrey] I'm not 100% clear what exactly happens now, this should be expanded.