Okay, we talked about this before we figured out the EIMML solution.
I've changed #6 to say:
Note: If the Sender or Updater of a message is listed in the
Addressing fields and is therefore going to be a recipient of the
message as well as the Sender, Chandler will be smart enough to
resolve the two messages as a single item with a single UUID via the
EIMML attachment.
On Mar 28, 2007, at 6:21 PM, Brian Kirsch wrote:
Hi Mimi,
> (From the Stamping spec:)
> 6. Note: If the Sender or Updater of a message is listed in the
Addressing fields and is therefore going to be > a recipient of the
message as well as the Sender, Chandler will be smart enough to NOT
pull down the
> message again into Chandler. However, the message will arrive in
the Sender's other email clients.
I strongly disagree with this. There are many edge cases here.
Selectively deciding what to download
based on who is in the addressing fields is not a good idea as
users addresses can change and more
than one Chandler can have the same email address.
The behavior you desire, which is to preserve the UID, Ical UID,
and any changes made after
the send is exactly what happens with my check in today.
-Brian
On Mar 28, 2007, at 3:11 PM, Mimi Yin wrote:
(From the Stamping spec:)
6. Note: If the Sender or Updater of a message is listed in the
Addressing fields and is therefore going to be a recipient of the
message as well as the Sender, Chandler will be smart enough to
NOT pull down the message again into Chandler. However, the
message will arrive in the Sender's other email clients.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
