Re: [Evolution-hackers] Rethinking account management

2011-03-29 Thread Matthew Barnes
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


Re: [Evolution-hackers] Rethinking account management

2011-03-29 Thread Milan Crha
On Tue, 2011-03-29 at 09:26 -0400, Matthew Barnes wrote:
 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.

Hi,
should it delete them too? I've a feeling there is no need for it,
especially when you want to have them as three separate independent
objects. But that's just a feeling.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Backend requesting arbitrary user input from frontend

2011-03-29 Thread Milan Crha
On Wed, 2011-03-23 at 19:04 +0100, Christian Hilberg wrote:
 Of course, this is going to be fun - how to tell which of the possibly 
 multiple EDS-frontends should receive the request? Ideally, the backends 
 should be unaware of EDS-frontends... trouble galore! :)

Hi,
Matt suggested in his Account management that the server will ask for
credentials with an information for which source this request is made,
so the auth_required signal may contain this information. I'll add a
strv parameter to that, just for being ready even for more expansion.

What kind of information will be known in this parameter depends on the
receiver for the signal. Let's have it opened for now, but I believe
this may cover your issue too.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers