Getting iCalendar import/export right

Meeting Notes

• DesignDevMeetingNotes20050223
• DesignDevMeetingNotes20050301

Goals

Perfect round-trip from Chandler

The process of taking an existing Chandler item, exporting/sharing it to iCalendar, then importing/sharing into another Calendar, needs to be completely lossless

Reasonably complete interoperation with other iCalendar software

iCalendar data created in other applications should be imported smoothly. Non-standard properties don't necessarily need to be preserved when imported into Chandler, but we should try to work with de facto standards

Issues

What makes an iCalendar VTODO into a Task vs. an EventTask?

iCalendar VTODOs have DTSTART and DUE (or DURATION which is almost but not quite equivalent to DUE), all three are optional. Would it work to say any event with a DTSTART, DUE, or DURATION should be an EventTask, not an Event?

The RFC says:

   A "VTODO" calendar component without the "DTSTART" and "DUE" (or
   "DURATION") properties specifies a to-do that will be associated with
   each successive calendar date, until it is completed.

I guess the other way of asking the question is, what should a Chandler EventTask be in iCal terms? Katie, Sheila and I had a brief discussion about it and the conclusion we came to was that for the user, a Chandler EventTask is really something they would have just put on their Calendar as an Event if they didn't have Chandler. In other words, the hypothesis is that users will want to see their scheduled tasks on their Calendar more than they will want to see it on their task list (especially since taskpads are barely used in most PIMs).

As for all of the various kinds of date attributes on Tasks in iCal, I think we want to ignore those for now. If a user sets one of them in another client however, we may want to take the earliest date and stick it in the alarm / tickler attribute for triage purposes so that the item pops up in the Now section of the Dashboard view as a born-again item when the alarm goes off. -- MimiYin 20050216

As much as possible, I want to avoid Chandler specific properties when we export iCalendar. This leads me to think about iCalendar -> Chandler first, because if this tranformation isn't surjective onto the Event and Task space, we'll need to add Chandler specific properties to make it so, or lossless sharing to iCalendar won't work.

What you're saying suggests to me that just because an iCalendar user has a dated VTODO doesn't mean Chandler should interpret that as an EventTask, it should still be a Task unless there's a Chandler specific property suggesting otherwise.

This is certainly not the end of the world, just sad from my little corner of the interop universe if EventTasks are going to be a major component of Chandler users calendar data. -- JeffreyHarris 20050217

All day events

Implementations and the RFC differ in how they represent all day events/anniversaries. RFC2445 says:

   The "VEVENT" is also the calendar component used to specify an
   anniversary or daily reminder within a calendar. These events have a
   DATE value type for the "DTSTART" property instead of the default
   data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
   MUST be specified as a DATE value also. The anniversary type of
   "VEVENT" can span more than one date (i.e, "DTEND" property value is
   set to a calendar date after the "DTSTART" property value).

To my mind, this last sentence means that an anniversary should have a DATE value type for DTSTART, and no DTEND or the DTEND is the same day. However, Outlook and iCal export all day events as having a DTSTART and a DTEND a day apart. Currently, importing iCal/Outlook style all day events works in Chandler (although they aren't properly tagged as all day, I need to fix that), importing events which are what I think of as RFC compliant doesn't currently work. Oops, I read the RFC wrong, I didn't read the next paragraphs carefully enough, "The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event.", which clarifies things a bit, I was wrong.

Currently, I treat VEVENTs that have a DATE value type as allDay Events. iCalendar allows such events to be multi-day, like a 3 day conference. Chandler's UI doesn't currently display this information and the event editing UI doesn't allow multi-day all day events. I filed this as bug 2512.

Similarly, VTODOs can have a DATE value for start and due dates, when this happens, since right now I'm importing VTODOs as EventTasks, I just set the allDay attribute. While the repository allows this, the UI certainly doesn't understand it. Would it make sense to add an allDay attribute to regular Tasks, for tasks that start, say, some time on March 12, and are due some time on March 19? If we do this, I wonder if instead of calling this attribute allDay, we should call it isDate, or better, hasNoTime (isDate doesn't imply the abscence of time to me). -- JeffreyHarris 20050218

Any time events

There's no obvious "any time during this day" property in iCalendar. Perhaps events with a DATE value type could be interpreted as meaning this, but that would be an interop nightmare. We may need to add a custom property for this.

It seemed like the LPFI folks used the All-day event feature when they really meant Anytime this day. We could follow suit? -- MimiYin 20050216

It seems to me that the main scheduling difference between "any time today" and "all day" is free/busy transparency. For reference, from the iCalendar RFC:

   Description: Time Transparency is the characteristic of an event that
   determines whether it appears to consume time on a calendar. Events
   that consume actual time for the individual or resource associated
   with the calendar SHOULD be recorded as OPAQUE, allowing them to be
   detected by free-busy time searches. Other events, which do not take
   up the individual's (or resource's) time SHOULD be recorded as
   TRANSPARENT, making them invisible to free-busy time searches.

I like the conceptual model of labeling a task or event like "Vote between 8AM and 6PM" as "any time", because voting at some point does take up my time, I'm just not attached to exactly when I do it. In terms of user affordances, "Any time" is probably a more approachable linguistic hook than "this is a transparent event/task", but "any time" has a more specific meaning than TRANSPARENT, so I don't think users would be served by only offering "any time" affordances but no separate TRANSPARENT affordance for events like birthdays.

Under the hood, "any time" could set time transparency to TRANSPARENT, in addition to having whatever additional semantic meaning we want to add beyond scheduling transparency (I imagine "any time" items might be rendered slightly differently from TRANSPARENT items in the UI).

If we do "any time" this way, exported events/tasks will need to contain a Chandler specific "any time" property. In this case I'd be fully in support of that, since we'll still be accurately exporting the scheduling meaning in TRANSPARENCY.

Or we could just decide to drop "any time" if it would be functionally equivalent to TRANSPARENT and we don't want want users to get confused by having two similar ways to do things. -- JeffreyHarris 20050217

Clobbering of Chandler specific extensions when Sharing

If a non-Chandler client modifies a shared event (another CalDAV client, perhaps), any Chandler specific properties may get clobbered. Probably when such items are synchronized, the abscence of a property shouldn't delete that property.

Should we implement VJOURNAL

A VJOURNAL is pretty much a dated note, I'll repeat the oft repeated idea that RSS fills this niche better than VJOURNAL. I haven't seen anyone using VJOURNAL. If we were going to import/export VJOURNAL data, from a Chandler perspective, how is a VJOURNAL different from a VEVENT?

VJOURNAL is more of a Chandler Note than an Event? -- MimiYin 20050216

Well, it's a Chandler Note with a meaningful date or datetime associated with it. Oops, I guess Notes have this, too, it's just not currently being rendered. So, to rephrase what I'm wondering, will anyone will ever want to export their Notes as VJOURNAL? It's no big deal to import VJOURNAL, but if I'm not private about my calendar and I just want to share everything calendar/task related, it would be nice to not include my random notes.

I guess in the UI for setting up export or a share there could be a checkbox for Notes (and Events and Tasks and EventTasks), and Notes could be off by default. OK, I've convinced myself I should implement VJOURNAL, but it won't surprise me if no one ever uses it. -- JeffreyHarris 20050217

Multi-line SUMMARY

I'm mapping SUMMARY into title. SUMMARY in iCalendar is allowed to have carriage returns. When a carriage return is imported, it's rendered a little oddly in wx because we're expecting title to be all on one line. Do we want to do anything special with a multi-line SUMMARY?

Is 00:00 duration the same as no duration?

Would it be possible and useful to allow users to select None for duration? I think this suggests duration is unknown. Right now one can set duration to 00:00, but this seems like spurious precision in the many circumstances where I don't know the duration of an event. As it is, I've got a bug in importing VTODOs and VEVENTs with no duration.

Other issues

Other attributes to worry about

• Triage status
• Privacy status
• Non-standard alarms: Chandler users will be allowed to set alarms on past events for triage purposes
  • This shouldn't be a problem, iCalendar VALARMS can be set to happen any time before or after the beginning, or for that matter the end, of a VTODO or VEVENT
• Labels