[Chandler-dev] Re: Decoupling "from" from "send as" in email,
and related issues
stearns at osafoundation.org
Wed Jan 31 18:55:02 PST 2007
Brian Kirsch wrote [comments on my decoupling proposal] (thanks!):
> 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 agree that's a good way to go after Preview, but was hoping that we
could get by with just some refactoring for now - thanks for the
> 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.
Oops, you're right - the EIM stuff would hold this (Last time I worked
on this was putting event info in the message, and we didn't have the
EIM stuff). It might be nice to add this to the stuff we prepend to the
body, which non-Chandler-users would see (but no additional X-header
would be needed for that).
>> 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
Yeah, we can definitely talk more about this. I *think* this is an
example: Hypothetically, let's say I start a conversation by sending you
a proposal for changing addressing :-)... In my message, "From:" is me
and "To:" is you. You edited my proposal and clicked Update, which sends
a message back to my Chandler; in your message, "From:" is you and "To:"
is me. My Chandler is going to update my original item when it gets your
message; however, it's going to have to be smart about which fields it
(Now that I write this, maybe your point about EIM takes over: both
messages will have the same toAddress and fromAddress values encoded, so
maybe there's not a problem on my end; however, that means there's a
problem to be handled on your end when you send the update back to me:
your Chandler needs to populate the email fields 'backwards' since
you're sending an update back.... yes, clearly I need to read the spec
again, and we can talk more then.)
>> 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.
I meant in and out of the persisted EmailAddress item: we take a string
from the detail view field and parse it into a bunch of EmailAddress
items that get persisted. Currently, we don't persist email addresses
that EmailAddress.IsValidEmailAddress rejects, but the design says we
should. I meant that we should be able to feed anything "into" an
EmailAddress, and later, get the same string back "out".
The design agrees with you that it's the SMTP server that'll do the
"rejecting" - I'm thinking that maybe we'd set a flag on the
EmailAddress to indicate that it needs correction in the UI? This would
mean that that address would appear to need correction in any email that
used it, since the EmailAddress object is shared that way - this might
not be a bad thing, though. An alternative to this would be to move
rejected EmailAddress references from the toAddress/ccAddress/bccAddress
reflists to new toBadAddress/ccBadAddress/bccBadAddress reflists, but
that smells bad to me.
> 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?).
I don't think the detail view can know: your SMTP server might accept
"bkirsch" by itself; all the detail view could really do is check for
gross structural errors (odd numbers of doublequotes, etc.), and since
the SMTP server's gonna do that anyway, why bother?
> 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.
Yes, good point - I think the changes I'm planning won't get in the way
> 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)
I'll look at this further, and the place(s) where you use this - maybe
we can simplify it and make it more flexible for both of us.
More information about the chandler-dev