Re: [Evolution-hackers] Rethinking account management

[Matthew Barnes <mbarnes redhat com>]

In last week's IRC meeting I promised more details about the file format
I'm designing for mail accounts.

I like the way Thunderbird splits accounts, identities and transports
into orthogonal concepts.  Each account has a default identity and
transport, but then you can go back and define additional identities and
transports.  We've had numerous requests for this capability over the
years, but we can't really do it with the current architecture.  Right
now you have to define a complete account for every different identity
you want.  So I'm trying to at least build Thunderbird's flexibility
into the file format, even if Evolution can't yet take advantage of it.

First, to clarify these terms:

Generally, a mail account describes a mailbox on some host that holds
your email.  A mail account object in Evolution will hold authentication
details for accessing that mailbox, and further settings for interacting
with it such as how often to check for new messages, whether to
synchronize the mailbox contents locally for offline viewing, etc.
Eventually I'd like to move new mail notification settings here as well.

A mail identity describes what information recipients will see when they
read your messages.  So things like your name, email address, reply-to
address, signature, etc.  A mail identity object in Evolution will also
describe things that Evolution should do automatically when composing
and sending messages.  This includes signing and/or encrypting outgoing
messages, automatically adding Cc: or Bcc: recipients, what folder to
put sent messages in, etc.  Eventually I'd like to move composer
preferences here as well: things like whether to compose in HTML mode,
preferred reply and forward styles, where to insert the signature, etc.

And last but not least, a mail transport is generally going to describe
an SMTP server and hold authentication details for it.


So.  My plan is for a complete mail account (as Evolution defines mail
accounts currently) to consist of three separate ESource objects, and
hence three separate key files, arranged hierarchically like so:

                         +--------------+
                         | Mail Account |
                         |   uid: aaa   |
                         +--------------+
                            /        \
               +---------------+  +----------------+
               | Mail Identity |  | Mail Transport |
               |   uid: bbb    |  |    uid: ccc    |
               +---------------+  +----------------+

The hierarchy just ensures that deleting the mail account from the
ESource registry will also take out the default identity and transport
for that account.

Here's a skeletal example of all three key files, minus all the extra
options.  Remember that each key file group, other than [Data Source],
is handled by a unique subclass of ESourceExtension.  So all I'm really
doing here is defining new ESourceExtension subclasses for mail stuff.
I'm also reusing existing extensions such as [Authentication] which are
also used in address books and calendars.


Mail Account (uid: aaa)
-----------------------

[Data Source]
DisplayName=My Account
BackendName=imapx
Parent=

[Authentication]
Host=my.mail.server.com
Method=ssl
Port=993
RememberPassword=true
User=mbarnes

[Mail Account]
Enabled=true
Identity=bbb    # Refers to the default Mail Identity (uid: bbb)

[IMAP+ Backend]
...backend-specific options go here...


Mail Identity (uid: bbb)
------------------------

[Data Source]
DisplayName=Matthew Barnes <mbarnes redhat com>
BackendName=
Parent=aaa

[Mail Identity]
Name=Matthew Barnes
Address=mbarnes redhat com
ReplyTo=
Organization=
Signature=
Transport=ccc    # Refers to the default Mail Transport (uid: ccc)


Mail Transport (uid: ccc)
-------------------------

[Data Source]
DisplayName=smtp.mail.server.com
BackendName=smtp
Parent=aaa

# The 'placeholder' key is just that.  Every group needs at least one
# key in order to appear in the key file, but there's nothing really to
# put here at the moment.  A little awkward, but I can live with it.
[Mail Transport]
Placeholder=For future transport options

[Authentication]
Host=smtp.mail.server.com
Method=none
Port=25
RememberPassword=false
User=


With this much figured out, I have removed EAccount and EAccountList
from libedataserver on my "account-mgmt" branch and am now trudging
through Evolution trying to put it back together using the time-tested
"figure the rest out as I go" approach.