Re: [Evolution-hackers] Rethinking account management

[Milan Crha <mcrha redhat com>]

On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote:
> Here's a few built-in top-level stub sources as trivial examples.  They
> don't do anything other than name a backend.  They would appear as bold
> group names in a source selector widget.
> 
>   1. Filename/UID: "on-this-computer"
> 
>      [source]
>      name='On This Computer'
>      backend='local'
> 
> ....
> The built-in "system" (a.k.a. Personal) source is an interesting corner
> case because it defines several different groups.  (The comments below
> are just my annotations, they would not appear in the key file.)
> 
>   Filename/UID: system
> 
>   [source]                    # org.gnome.Evolution.Source
>   name='Personal'
>   parent='on-this-computer'
>   
>   [extensions/address-book]   # org.gnome.Evolution.Source.Selectable
>   color='#000000'             # would not be used in the UI
>   enabled=true                # would not be used in the UI
> 
>   [extensions/calendar]       # org.gnome.Evolution.Source.Selectable
>   color='#becedd'
>   enabled=true
> 
>   [extensions/task-list]      # org.gnome.Evolution.Source.Selectable
>   color='#becedd'
>   enabled=false
> 
>   [extensions/memo-list]      # org.gnome.Evolution.Source.Selectable
>   color='#becedd'
>   enabled=false

	Hi,
it's pretty confusing to me. I understand from the above that there are
two files, one for groups, which is stored in system directory, and
"one" for real sources, which is stored in user's home.

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.

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.

It seems to me that there is no difference between the file in system
and home directory, both are using [source], but each for a different
purpose. I do not think it may work well.

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.

Well, it's not straightforward, from my point of view. I would rather
name groups [group], avoid confusion, and be able to define all this in
one file, thus for usual user they will be able to distribute only one
file with predefined account settings instead of many. Of course, the
groups should either have the 'uid' defined in the file, or it should
"inherit" uid from the file name itself.

Filename: Exchange my-company

[group]
name='Exchange my-company'
backend='exchange'
server='my-company'
username='me'

[source]
color='#FEFEEF'
parent='Exchange my-company'

[extensions/mail]
enabled=true

[extensions/addressbook]
fragment='personal/Contacts'
name='Contacts'

[extensions/addressbook]
fragment='personal/second-contacts'
name='second-contacts'

[extensions/calendar]
fragment='personal/Calendar'
name='Calendar'
last-notified='2010-10-10T10:10:10'

[extensions/calendar]
fragment='personal/second-calendar'
name='Second Calendar'
color='#80FF80'

...

Well, you cannot have two groups with the same name in the key file,
thus you really meant to have one file per each ESource/EAccount + one
file for the group definition, all these put into one folder in the home
(+ system group definitions in system folder)? I do not like the idea
much, but I agree it can work.

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?

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?

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.
	Bye,
	(slightly confused) Milan