Hi Mimi,
After reading through this proposal I have to wave some large flags
that I personally don't think this is doable for Preview. I think we
should focus on the simpler Edit / Update workflows and get those
right before tackling any complex forwarding logic. It is just too
late in the development cycle to add significant and challenging new
features.
See the rest of my comments in line.
-Brian
On Feb 17, 2007, at 12:08 AM, Mimi Yin wrote:
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.
doable
+ Forwards contain EIML and .ics attachments (if necessary) to
capture non-email metadata
doable
+ 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?)
This is not something I am willing to commit to in the Preview
timeframe given my other tasks.
+ Chandler recipients parse the EIML attachment and can edit/update
the Forward.
I would need more clarity here. If the forward is just a new Edt /
Update workflow then it might be doable.
+ 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.
This concerns me. Why would the sender end up with two copies?
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:
If a forward has the EIML of the other item then it has no identity
of its own. Meaning what if I stamp the forward as an event and add
data. That data would not be reflected in the EIML unless two items
EIML info was wrapped in the message (the original and the forward).
Again, I think this is getting too complex for Preview.
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
