[Chandler-dev] Decoupling "from" from "send as" in email,
and related issues
stearns at osafoundation.org
Tue Jan 30 16:59:58 PST 2007
I took over this small-sounding bug from Reid:
Add From: field to Detail View
The reporter didn't realize that "From:" (with the account-picker popup)
turned into "Send as", and that the rest of the implementation of the
byline mechanism hasn't been implemented yet. While investigating what
"the rest of the implementation" might be, I ended up also taking these
Decouple from/to from email
Implement "sent by/edited by" and "send via" widgets
Addressing fields should preserve non-email addresses
Left-align byline with Title and Location fields
Byline shouldn't be editable
In IRC, Brian suggested he'd like to hear more about my strategy for
fixing this stuff, so here goes:
First, bug 7430: "Decouple from/to from email". There are separate
issues here: First, "from".... the design calls for a Communications
stamp "From" field that's distinct from both the "From" and "Reply-To"
headers on the message. I'm intending to rename the
EmailStamp.fromAddress attribute to sendAsAddress; the mail service
layer will use this attribute to make the From: header on the outgoing
message. Once I've verified that nothing broke, I'll add a new
attribute, fromAddresses, that's a list of addresses for the "From"
field, and I'll add another X-Chandler-From header to pass it between
Chandlers in the message.
As for decoupling "to", I think that just indicates that we may need to
be flexible as we translate the addressing fields between layers (either
between mail-service message and the the EmailStamp addressing fields,
or between the EmailStamp fields and the UI), because we (re-)use one
item for all communications in a conversation: an item you send may be
updated by an email you later receive. (I need to study the spec more
Bug 7765 ("Addressing fields should preserve non-email addresses") turns
out to be more complex than it looks. Currently, our model for an email
address is an email address (eg, stuff, followed by "@", followed by
some definition of "a domain name" like foo.com), and optionally a "full
name". We sometimes try to parse these things from a single string, and
if we get rid of the requirement for a well-formatted email address, we
won't be as able to tell what's "email address" and what's "full name".
The strategy I want to start with is: change EmailAddress's parsing code
to treat a string with no "@" as a valid email address with no "full
name" (this way, when we format it, it'll come out as it went in, and
round-tripping will work).
Bug 7764 ("Add From: field to detail view") will be easy once the
underlying fromAddress/sendAsAddress attribute confusion is worked out.
Bug 7424 ("Implement 'sent by/edited by' and 'send via' widgets") really
means "finish the byline work" - most of the cases are already
implemented, but need work around visibility or labeling changes.
Bug 7701 ("Left-align byline..") and bug 7620 ("Byline shouldn't be
editable") are small detail-view-blocks cleanups.
More information about the chandler-dev