Hi Mimi,
I reviewed the spec and there is a lot of detail on how the stamping
UI and Content model interact for the Edit / Update work-flows. These
look really good.
I would like to clean up the section regarding the sending and
receiving of items via email.
First, there is no mention of EIM records. These are now the
transport mechanism for Chandler data in mail messages and are very
important.
Every mail sent from Chandler must by definition have an EIML
attachment that represents the item otherwise there would be no way
to trigger the edit / update workflow.
It is the same notion as every mailed Event including an .ics
attachment.
Speaking of .ics, for the Edit / Update work-flows there is no need
for .ics files.
Chandler still send .ics attachments with messages that are stamped
as an Event. But the .ics attachments are useful only for other
clients (ICal) and not for Chandler. Everything will be based of the
EIML records.
A Chandler to Chandler communication (Chandler Headers) will never
utilize the .ics file since the EIML attachment in the message takes
precedence.
The only time a .ics file would be processed is if the mail message
did not contain an EIML attachment. Which by definition means it was
not sent from a Chandler client.
Just to clarify, every user participating in an Edit / Update will
receive an email containing some text representing the workflow even
the sender.
Chandler will ignore any messages sent from itself i.e. it won't try
to parse the EIML information. The message is meant as a notification
in the users email client.
Since for Preview, we will have only three stamping types I would
like more detail on exactly what the user should see in the body of a
mail message sent from Chandler and viewed in his or her email client.
As we currently do with events some attempt should be made to bottle
up the attribute info in to a textual representation.
The spec mentions taking additional attributes and placing them in
the body of the message.
Which attributes would this be for a Task Stamp? A Communication
Stamp? etc.
Also the mail message body and the Chandler note body are now
complete separate entities in an Edit / Update workflow. Which gives
us much more flexibility.
The EIML will contain the body text of the item intended to be viewed
in Chandler. The mail message body will contain information intended
to be viewed in another mail.
The spec mentions an Edit / Update workflow around an Event
invitation. An Edit / Update workflow can occur on any Item in
Chandler regardless of stamping. I.e. as long as the item is sendable
(has a communication stamp) then it can participate. Is this correct?
Overall, I think the spec looks really good.
The open issues are:
1. What type of messages get a EIML attachment (stamped as task,
event, etc)?
2. Is there a way to prevent having to attach EIML to every message
sent from Chandler?
If we can flush out these last mail related details we should be good
to go :)
-Brian
On Feb 13, 2007, at 4:53 PM, Mimi Yin wrote:
Please review and reply with comments/questions. In particular, I'm
not sure if there have been changes in thinking around edited by/
last modified that should be captured in the spec. Grant?
http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_7/
Stamping-0.7.html
I have updated the Stamping Spec from the following wiki documents:
+ http://wiki.osafoundation.org/bin/view/Journal/EmailStamping20061121
+ http://wiki.osafoundation.org/Journal/
DashboardSharingCommunicationsRecurrence
I did not incorporate: http://wiki.osafoundation.org/Journal/
NoDataLossProposal. I think we should let that proposal solidify
before adding it to the Sharing spec and then cross-linking from
the Stamping spec. For now, I have a link in the Stamping spec to
the wiki spec.
Most of the changes are just documenting things we've already
agreed on in meetings and on the list. Hopefully, nothing here is
surprising :o)
+ Calculating whether message items are Inbound or Outbound, aka
fromMe, toMe and attendant UI behavior
+Nit-picky scenarios about what to do when replying to a message
where the Sender is *not* mentioned in Addressing fields. (Answer:
automatically add Sender to the CC: list).
+ Nit-picky scenario about what to do when the Sender of a message
*is* mentioned in Addressing fields. (Answer: don't pull down
duplicate message from server.)
+ Sending, Editing and Updating Recurring Events (same as what was
in the Dashboard spec).
There is also a body of material around how to package up Chandler
items in Emails. I will track that in the Email spec with a cross-
link from the Stamping spec.
Thx!
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
