Hi Mimi,
1. If Sender of the message (Send as: byline field) is not the same
as the From: field, then the message requires an EIML attachment.
This concerns me. Although from a technical standpoint this is doable
I am worried that users will not
understand that the from has to be different to start a Edit / Update
work-flow.
Does anyone else think this might be confusing?
-Brian
On Feb 15, 2007, at 9:44 PM, Mimi Yin wrote:
On Feb 14, 2007, at 6:02 PM, Brian Kirsch wrote:
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.
Yes, I was hoping to capture that in the Email spec after talking
more with you and others. It wasn't clear to my from my notes,
exactly how this would work. I will incorporate the stuff below
into the Email spec?
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.
Yes. In the Edit/Update workflows though, I wanted to show how
sending and updating from Chandler will work with both Chandler and
non-Chandler users.
A Chandler to Chandler communication (Chandler Headers) will never
utilize the .ics file since the EIML attachment in the message
takes precedence.
Okay, I can clarify that in the spec.
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.
Yup
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.
Yes, I believe that's in there.
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.
I believe there is a pass at this in the Email spec, but I will
revisit that to make sure it is still up to date. Roughly, it
should be something like this:
POSSIBLE KIND-COMBINATIONS:
+ Message
+ Task
+ Event
+ Recurring Event
+ All-day Event
+ Recurring All-day Event
===
xxx sent you a <KIND> from Chandler at xxx:
From:
To:
CC:
<TITLE> at <Location> from/on <DATE/TIME> <OPTIONAL TIME ZONE>
until <OPTIONAL RECURRENCE END-DATE>
<NOTES>
===
Language for recurring events:
Daily: Every day from xxx to yyy.
Weekly: Tuesdays from xxx to yyy.
Biweekly: Every other Tuesday from xxx to yyy.
Monthly: Every month on the 17th from xxx to yyy.
As we currently do with events some attempt should be made to
bottle up the attribute info in to a textual representation.
Yup.
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.
Great, I will keep that in mind and spec out both what appears in
the Chandler body and what appears in the Message body.
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?
Yes.
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)?
I think every kind of item could potentially get an EIML
attachment. Even plain messages have an extra Chandler 'alarm'
field that is non-standard. Also, there are all those funky
Addressing fields stuff where the From field isn't necessarily the
Sender, etc...
2. Is there a way to prevent having to attach EIML to every
message sent from Chandler?
Can we figure out when/if the Addressing fields are non-standard
and only attach EIML in those cases? Okay, so I think the criteria
are:
Also, I need to note that:
BCC, Triage status, Alarms and Event status are never sent out in
the EIML attachment. If users are sharing those attributes in a
shared collection, we will just let the sharing sync update those
attributes. Email messages and subsequent Updates will never send
out those attributes, because we can't tell if the email recipients
are sharees.
If we can flush out these last mail related details we should be
good to go :)
-Brian
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
