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
confirmation.
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
Skype.
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
updates.
(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
of that.
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.
Thanks again,
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
