Hi Brian,
On Feb 20, 2007, at 11:37 AM, Brian Kirsch wrote:
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.
Yup that's perfectly reasonable. I think we can do something simpler.
See below...
See the rest of my comments in line.
-Brian
On Feb 17, 2007, at 12:08 AM, Mimi Yin wrote:
+ 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.
Okay. I think then the easiest way 'out' of this is to just package
up any event or task information in an .ics attachment and have other
Chandler recipients of the forward reconstruct the forward as best
they can from the .ics attachment. Now that I'm thinking about this
again, this may work just as well as the concoction I came up with
above.
+ The Addressing fields will be the same as the Forward item's
addressing fields. (Same as above.)
+ Event / Task metadata will be parse via the .ics attachment.
+ The only open issue is the Notes field. What do Chandler recipients
see in the Notes field? The Notes field from the .ics attachment? Or
the Notes field from the Forward message. How does this get resolved
today? Do they just get concatenated?
Oh but ic there are more problems below...
+ 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.
Yup, just another edit/update
+ 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?
This is a tongue-twister...so bear with me. Let's say I forward you a
Task. The Forward item in my Chandler is just a message to me and is
a separate item from the original Forward-ED Task item. But if you,
another Chandler user receives the Forward item, your Chandler parses
the item as a full-blown Task. So if you edit and update the item, I
will have my version of the Forward item turned into a Task as
well...which means that I will now have 2 copies of the 'same' Task
in my Chandler: the original one and the one I forwarded that you
edited and updated.
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.
Okay. This could happen with the .ics attachment proposal above as
well. I think further 'Stamping' of Forward items is unlikely. But ic
that we have a serious problem if user do it. I can imagine various
complicated ways to deal with this more elegantly, but for Preview,
let's keep it simple.
Let's have Forwards remain 'in-line as text' forwards with no .ics
attachments...and add EIML and .ics attachments based on the Forward
item itself...NOT on the item being Forwarded. Does that make sense
to you?
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
