I think we could decouple this stuff pretty easily... its done this way
in the Thunderbird backend, though the UI was only recently exposed in
1.5 - there is a concept of an "Identity", (similar to a "contact" as we
define it, but more mail-specific) and "Account" and an "Incoming
Server" (or "Inbox")
The basic idea is that an Account consists of one Incoming Server, and
one or more Identities. The "Account" is just a container, and has very
few attributes of its own.
Account
+---IncomingServer
+---Identity
Identity
etc...
Further, an Identity could stand alone without an account.. If an
account is associated with an identity (think bidi-references) then the
mail composer library would use the data in the account/incoming server
to determine things like what "Sent" folder to use, etc.
Reply-To is an attribute of the identity, not the Incoming Server. So to
answer Morgen's question, I think that rather than think of the Reply-To
as somehow connected to the account on the IMAP/POP server, think of it
as a detail of the Contact.
In our world, Reply-To is really an annotation of the contact by the
mail code. that would be pretty easy:
class MailContactInfo(schema.Annotation):
schema.kindInfo(annotates=pim.Contact)
replyTo = schema.One(schema.Text)
Alec
Mimi Yin wrote:
Is there a Reply-to field right now for Incoming mail? I think the
Reply-to value in the Outgoing mail account settings could override
whatever email address was entered for Incoming mail. In most cases,
it will probably be the same email address.
This solution is just appealing because it requires the least amount
of change. See more below about the unified account approach.
On Feb 8, 2006, at 4:38 PM, Morgen Sagen wrote:
On Feb 8, 2006, at 4:16 PM, Mimi Yin wrote:
We want to allow people to easily send out invitations in 0.7
without having to:
+ fill out incoming mail account information, thereby
+ sending Chandler into the throes of trying to download your email
into the repository.
Currently, if you fill out the SMTP account information, you have to
fill out Incoming mail account information as well (so that there's
a reply-to email address for outbound mail.)
Here are a couple of proposals for how we might de-couple incoming
and outgoing mail accounts in 0.7:
+ Add a "Reply to:" field to the SMTP account form. Allow users to
send email by just filling out Outbound mail information without an
Incoming mail account. AND/OR
At first this one appealed to me, but then what happens if you create
an SMTP account (filling in a reply-to address), and then create an
IMAP account (also filling in a reply-to address). When you send
mail, which reply-to does the mail framework use? You could follow
the rule that if the IMAP/POP account you're using to "send from" has
a reply-to address filled in then use it, overriding what's in the
SMTP account.
+ Unify Inbound and Outbound mail account info into a single Mail
account. Users can optionally fill out the incoming mail server. AND/OR
+ Add a checkbox to the mail account form that is un-checked by
default: Sync automatically.
Actually, unifying Inbound and Outbound into a single Mail account is
rather appealing; the account edit dialog could have an account-type
listbox with three choices: IMAP, POP, or "Outbound only", and a
single reply-to field for the whole "account". The only downside is
that two Inbound accounts couldn't share the same Outbound account,
but that's probably not a big deal. This also means the awkward
"use as default 'from' account" radio button gets replaced by the
more natural "use as default mail account". So +1 to the
unification, but I don't think we need the "sync automatically"
checkbox if we have the 3-way account-type listbox I described
(unless you include that checkbox in addition to the listbox).
I think this approach is ultimately more usable, since people think
about email accounts as both Inbound and Outbound. In the future we
can have something that stores SMTP accounts so that you can reuse
them across multiple accounts, but for now, having users enter the
same info a few times is probably okay.
Do you think we need an Outbound only? We could just make the Inbound
mail server info optional and force the user to Sync it manually.
Otherwise, I think the first approach is cleaner.
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
