Hi Bryan,
See comments inline.
On Jan 30, 2007, at 2:59 PM, Bryan Stearns wrote:
I took over this small-sounding bug from Reid:
https://bugzilla.osafoundation.org/show_bug.cgi?id=7764
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 related bugs:
https://bugzilla.osafoundation.org/show_bug.cgi?id=7430
Decouple from/to from email
https://bugzilla.osafoundation.org/show_bug.cgi?id=7424
Implement "sent by/edited by" and "send via" widgets
https://bugzilla.osafoundation.org/show_bug.cgi?id=7765
Addressing fields should preserve non-email addresses
https://bugzilla.osafoundation.org/show_bug.cgi?id=7701
Left-align byline with Title and Location fields
https://bugzilla.osafoundation.org/show_bug.cgi?id=7620
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.
Ideally, we would refactor MailStamp to be a Generic
CommunicationStamp that could have a Mail annotation or a pointer to
a MailItem. That way we could preserve the separation of
Chandler types from traditional mail types. However, given the time
to Preview refactoring the fromAddress to sendAsAddress would work.
I would like to hear more about the use of the X-Chandler-From
header. Why would this be needed? I would have thought the Chandler
"non-email address" from info would be contained in the
EIML records attached to the mail message. Since no other clients
understand the X-Chandler-From I am not sure what the benefit is.
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 here...)
Can you talk more here about how the implementation of 'to' could be
more flexible. What specifically would you change?
For Preview the 'to' would still contain email addresses although the
number of email addresses can grow or shrink through a conversation.
I.e. the list of who is participating in an Edit / Update workflow
(the to field) can change by adding or removing 'to' email addresses.
Also one thing that has not been mentioned is the cc and bcc. Do
these fields need to be 'decoupled' as well?
Again I would like to hear your thoughts more on the term 'flexible'
as it relates to an implementation. Perhaps, we should chat on IRC or
Skype.
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).
When you say come out as it went in I am a bit confused. If the
emailAddress field does not contain a valid address then it won't go
out cause the SMTP server will reject it.
However, you are correct that the only time a email address really
needs to be valid is the moment before a send. We could refactor so
that right before
calling the mail service to send the item the detail view checks
validity via the EmailAddress.isValidEmailAddress on each string
token in the 'to' field (cc? bcc?).
The mail service as I mentioned on IRC is more flexible with the
validity of mail addresses. Mail coming in from a POP or IMAP server
may contain an invalidly formated email address but we still need to
capture that address to show to the user.
If one uses the EmailAddress.getEmailAddress method it contains the
validation and me translation logic and is currently quite inflexible.
In the mail service I use:
# Do we already have a EmailAddress item for this email address
address = EmailAddress.findEmailAddress(view, addr)
#Nope manually create a new one bypassing validation logic and me
# address translation
if address is None:
address = EmailAddress(itsView=view,
emailAddress=addr, fullName=name)
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.
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
