(Note: this page was largely written before I'd either talked to other folks or studied what's already been done. Consider it obsolete...)

Event & Sharing Invitations in the Detail View

Two of the 0.5 goals involve special handling of event and sharing invitations in the detail view:

• When an Event invitation is received, a mechanism should be provided to create an event (with the same attributes (time, location, etc) as the original calendar-email item).

• Sharing invitations need to give the user a button to start sharing of the specified collection, instead of showing the message body. (At the moment, sharing invitation UI is handled as a special case when receiving mail; an alert is presented, giving the user one opportunity to accept the invitation.)

These situations are different, but have one thing in common: to perform special handling on the receiving end, additional information needs to be sent in the message; currently, for sharing an item collection, a reference to the shared item collection is included in a special header:

X-Chandler-Sharing-URL: http://server.com/path/00000000-0000-0000-0000-000000000000

Expanding on this, sending a mail+calendar item might likewise encode the calendar attributes like:

    To: you@example.com
    From: me@example.com
    Subject: Our meeting
    X-Chandler-CalendarEventMixin-startTime: 20050103T1530
    X-Chandler-CalendarEventMixin-duration: 60
    X-Chandler-CalendarEventMixin-location: My office

    Let's meet to discuss special mail headers. See you there!

(The event's body is meaningful to the user, so we can't use it for storing this metainformation. Currently, it appears that the sharing invitation's body is used for a generic "This is a Chandler-to-Chandler message" explanation, though I expect that the item collection's body would be a more useful thing to put here.)

Other questions:

• What determines which attributes get included? Hard-coding calendar info only would be limiting; instead, one idea would be to use a Cloud specification (though the repository probably wouldn't need to be involved in formatting the header fields) on each mixin kind.

• how are the attributes formatted? (can the repository translate all of its types to/from an XML-compatible representation?)

• what happens on the receiving end? The detail view would look for the custom fields, and if they were present, give the user extra UI (for example, when displaying an email and the appropriate CalendarEventMixin-related fields are present, an "add to calendar" button that would effectively stamp the email as a calendar event, copying the field values to the CalendarEventMixin attributes in the newly-stamped item).