Re: [Evolution-hackers] Rethinking account management

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2010-11-11 at 08:55 +0100, Milan Crha wrote:
> Will be there any kind of property inheritance? As in your example
> above, I would like to define the 'color' in the [source]
> key-file-group, thus all extensions will inherit it, but, if user
> changes color for one of them, then it'll create its own key and it will
> be used instead of the parent's.

Certain keys can be inherited, yes.  We've already seen inheritance in
some examples I gave with the 'backend' key.  Another example might be
an 'enabled' key, which could work similar to widget visibility in that
a child source may have enabled=true, but it's not -really- enabled
unless all of its parent sources are also enabled.


> Maybe it's not the best example with the color, but imagine the Exchange
> account, I would like to define server address and credentials,
> connection setup and such, in the parent, and the children
> (mail/calendar/...) will inherit this.

I imagine that too.  I think groupware backends will have considerable
freedom to distribute information across sources however they want.

The API isn't nearly finished yet, but at the moment I'm thinking of
embedding a GNode within each ESource object to represent the source's
position in the hierarchy.  The GNode's data value would point back to
its ESource object, so you can access parent, sibling or child sources
through the GNode API.

For example, fetching account information from a parent source might
look something like:

   /* Suppose ExchangeAccount wraps a GSettings object that
    * manages an [extensions/exchange-account] group in the
    * parent of a calendar source.  The "exchange-account"
    * group holds the server address, credentials, etc. */

   ExchangeAccount *account;
   ESource *parent;
   GNode *node;

   node = e_source_get_node (calendar_source);
   parent = E_SOURCE (node->parent->data);
   account = e_source_get_extension (parent, "exchange-account");

   /* This retrieves the value of:
    *
    * [extensions/exchange-account]
    * hostname='my.exchange.server.com'
    */
   hostname = exchange_account_get_hostname (account);


> Imagine the exchange account again. Right now you define an account
> name, and this name is used as a source group name in Calendar and such,
> same as in mailer. With that you wrote I do not see a way of achieve
> that just from the user's home. Or is this based on the existence of the
> parent/backend key in the [source] key-file-group? In that case the
> exchange account will have actually two files instead of one in the home
> directory, one for group definition and one for real sources? It's
> unnecessary, right? a) you would search for parents, in home and in
> system directory. b) you should be able to easily distinguish between
> group definitions and real sources definitions (all are named [source]
> in your proposal) and be able to _easily_ reconstruct them.

A groupware account will likely consist of a collection of key files,
but you won't be interacting with key files directly, as shown above.
Some central ESource registry will load all the key files, create an
ESource object for each of them, arrange them in a hierarchy, and emit
signals when the "sources" directory changes.


> Also, remember that users can name their accounts whatever they want,
> but not every latter is usable for the filename - so the files will be
> either meaningless strings or something descriptive?

Built-in sources can have meaningful UIDs like "on-this-computer" or
"on-the-web", since those key files will be installed as part of the
E-D-S package.  User-created sources will use the same generated UID
strings that we're using now, via e_uid_new().


> The last two questions (and I see I mostly answered above questions
> myself), how will be the group definition propagated to mailer,
> respectively how will be defined the POP account, which doesn't have a
> group in the folder tree, same as the mbox, which is hacked in and
> hidden in the background? Will these two kinds also require its own
> group file (for the 'backend' key) or not?

A pop account would look something like:

[source]
name='My POP Account'
parent='on-this-computer'
backend='pop'

[extensions/mail]
... account details ...

The folder tree will have to give special treatment to accounts that
rely on the built-in local mail store, but we already do that.


> Because you have [source] for groups and [source] for pseudo-sources
> (the real source is at the [extension/...]), then will I be able to
> define a child of the source, not of the group, and it'll be propagated
> to the UI? Just an idea, not that I think it would be usable.

I'm purposefully leaving the file format very open-ended and flexible.
The API will be less so.  There's all kinds of key file configurations
you can think up that Evolution can't support right now.  We can either
decide it's an invalid configuration, or perhaps it could lead to a new
feature.  That's why I'm leaving it open-ended.


Hopefully I've made you slightly less confused and not more.  :)