So as I mentioned in my last email announcing the Email spec updates,
spec'ing out Forwarding turned out to be more painful than I had
anticipated, and I was already dreading quite a bit.
So here goes. In a world where we're shipping 'real Chandler items'
around, not just text. What does it mean to 'Forward' a Chandler item?
Outlook's model:
+ Outlook doesn't allow invitees to events to directly 'edit' other
people's invitations to say, add other invitees.
+ Instead, invitees can add other invitees by Forwarding an invite to
somebody 'on behalf of' the original event organizer.
+ If the recipients of the Forward accept the invitation, they are
added to the invite list.
In other words, Outlook essentially Forwards the original invite and
updates from recipients of that Forward, affect the original invite.
For some reason, I don't think we want to follow this model in
Chandler. For one, we *already* allow recipients of Chandler items to
directly edit and update 'other people's items'. So Forward should do
something different.
PROPOSAL - I badly need a reality check on how feasible this is. This
is just my first random design swipe at the problem. Let's follow up
with more discussion to do something that's reasonable for Preview.
+ Forwards are just message items.
+ Forwards contain EIML and .ics attachments (if necessary) to
capture non-email metadata
+ EIML attachment is a hybrid mix of the stamps from the original
forwarded message + Addressing and Notes fields from the Forward
itself (bkirsch: Is this significant, extra work?)
+ Chandler recipients parse the EIML attachment and can edit/update
the Forward.
+ This means that the original Forward message could get Updated to
become a full-fledged event on the calendar and/or task on the task
list. As a result, the sender of the Forward might end up with 2
versions of the same event on the calendar or 2 versions of the same
task on the task list...being updated by 2 different sets of people.
I think that's okay, because there are use cases where this is
useful. I remember this being something we discussed at great length
a year ago with Alec Flett and Mikeal. Sometimes you want to
collaborate on the same item with 2 different sets of people, we do
this all the time by splitting email threads. For example, you might
be coordinating 1 Wedding rehearsal dinner with the caterer and the
bridal party and want to keep those conversations separate.
Here's what's in the spec.
Forwards do not inherit the task/event stamps from the original
message Item. Forwards are separate message Items with their own
UUID. However, Forwards contain the original item as an EIML and/
or .ics attachment under the the same conditions described above for
Sending Items. The Forward message Item itself looks like the following:
Forwards are addressed in the following way:
From: (Original msg) = From: (Forward)
To:, CC: and BCC: are blank
Fwd: is prepended to the Title of the Item
Chandler will automatically place the cursor at the top of the Notes
field.
Chandler will add: Begin forwarded <KIND-COMBINATION>: to the top of
the Notes field, 2 line breaks down from the top of the Notes field.
For a list of all the possible Kind-Combinations, please see both the
'Sending Items' and 'Receiving Chandler Items in generic email
clients' section above.
Chandler will "forward the item as in line text" which will look
like: (Fields appear, only if applicable.)
Begin forwarded <KIND-COMBINATION>:
From:
To:
CC:
Sent by xxx on yyy
<TITLE> at <Location> from/on <DATE/TIME> <OPTIONAL TIME ZONE> until
<OPTIONAL RECURRENCE END-DATE>
<NOTES>
A ">" token at the start of each line.
Chandler will attach an .ics file and an EIML file to the Forward if
the message being forwarded was a task, event or had irregular
Addressing fields (as per the rules outlined above in the 'Sending
Email' section).
The EIML attachment will inherit any Task or Calendar stamps from the
forwarded message.
The 'Notes' field of the EIML attachment however will be taken from
the body of the Forward itself.
Users receiving the Forward in Chandler will parse the EIML
attachment, if there is one.
Users receiving the Forward in other email clients will see the .ics
attachment if there is one.
We realize there will be information duplicated in the message body
and in the attachment and that is actually by design, to provide
email client recipients with a way to preview the event Item before
adding the .ics file to their calendars.
Chandler recipients of the Forward can edit and update the Forward
like any other Chandler communication. Doing so, will update the
Forward message item for all recipients of the Update.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
