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 <mbar...@redhat.com> BackendName= Parent=aaa [Mail Identity] Name=Matthew Barnes Address=mbar...@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. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers