Hi Mimi,
See comments inline.
-Brian
On Feb 23, 2007, at 5:14 PM, Mimi Yin wrote:
Hi Brian,
Thx for reviewing these changes so quickly...see in-line:
On Feb 23, 2007, at 5:32 PM, Brian Kirsch wrote:
Hi Mimi,
I reviewed the latest spec. Here are the questions and comments I
have.
First, you list out the various kind combination examples of what
should appear in
the body of a message. Those look good. What I am not clear on is
what should appear
in the body / subject of an item that is just stamped as a mail
message. It seems in that
case we would not want to prepend all that extra info such as kind
combination to the message.
Let's not put anything extra in the message body if it's just a
message.
+1
Second, I am a bit confused on the forward case. Currently when a
user hits forward if the
original message was also an event that events info is packaged as
an .ics and sent along with
the forward. If the user then stamps the forward as an Event we
send both the original mails .ics and
the forwards .ics.
How does this get parsed on the receiving end in Chandler?
Which .ics file do we use to add the item to the calendar? I'm
proposing that we don't packaged up the original 'Forwarded
message' as an .ics or an EIML. Instead, we package up the Forward
message itself in an EIML attachment and add an .ics attachment if
the Forward message is stamped as a task and/or event. Meaning,
Forwards are just message items and behave like all other message
items.
+1 I think this is the best solution for Preview.
How is this suppose to work with EIMML?
Are we suppose to package the original messages EIMML? What
advantage would that be?
If you could provide more detail in the forward case to exactly
what EIMML and .ics are suppose to
be attached to the forwarded message that would be a big help.
I also not clear on this statement taken from the spec:
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.
Is the kind-combination based off the original message or the
forwarded item?
It's based off the original message.
+1
See the rest of my comments inline:
Thanks,
Brian
On Feb 23, 2007, at 6:18 AM, Mimi Yin wrote:
Hi
I went to update the Email spec with this stuff and I ran into a
few more wrinkles. I attempted to iron them out :o) and this is
what I ended up with...is this reasonable for Preview? (I've also
logged a bug to track this issue: https://
bugzilla.osafoundation.org/show_bug.cgi?id=8209)
What appears by default in the byline?
For non-message items: Created by, Edited by
* Full Name associated with 1st Sharing account; if there are
no Sharing accounts;
* Don't show the byline
Sharing accounts don't have an Email Address or Full name
associated with them. They do however have a username.
Hmmm, when you sign up for a Cosmo account, you need to fill that
information out. If we don't have access to that, then we can just
use the user name.
Open issue: What if the user has multiple Sharing accounts and
the same item is shared on multiple accounts?
I guess we can use the first account for now.
For draft message items: Send as, Edited by
* Email address associated with 1st Outgoing email account
user has successfully filled out; if there are no Outgoing email
accounts...
* Email address associated with 1st Incoming email account
user has successfully filled out; if there are no Incoming email
accounts;
* Email address associated with Sharing account; if there are
no Sharing accounts;
* Don't show the byline
I don't fully understand this logic. But I do have an alternate
suggestion. Today, I checked in
code to smartly find the me address in Chandler. If there is no me
address filled out in the
default incoming account (which is the primary value used to
determine the me) I now scan
all mail account till I find an Email Address and return that
instead. The order of the scan is
search all IMAPAccounts then POPAccounts then SMTP Accounts.
So calling EmailAddress.getCurrentMeEmailAddress(view) will return
the closest approximation of
what the me address is. It seems this same logic should be
leveraged for the Send as, Edited by instead
of what you have listed above. It should be noted that what you
detailed and what getCurrentMeEmailAddress return are pretty much
the same. The difference is in the search order.
Chandler has always used the email address in the default incoming
account as the me address so we
should keep this consistency.
Well the thing is you can't send out email with just an Incoming
Email account. So there's a higher chance of success if we use an
email account associated with an Outgoing email account for the
Send as field.
But if it's simpler to keep the logic we have now, that's fine...we
can address this again post-Preview.
Also as stated above Sharing Accounts do not have a user defined
email address associated with them.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
