Re: [Evolution-hackers] Rethinking account management

[chen <pchenthill novell com>]

On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote:
> As part of our transition from GConf to GSettings, which Rodrigo Moya
> has graciously been helping with, I've put some thought into addressing
> the XML string lists which we currently store in GConf under "accounts"
> and "sources" keys.  We've known for years that this is a really bad
> approach, and I don't think I have to enumerate the reasons why.
> 
> To this day many users assume they can backup or copy their Evolution
> accounts by simply archiving or copying their Evolution data directory,
> and no amount of repetition about the "correct" way to do it seems to
> stick.  And predictably so.  Correcting people's reasonable expectation
> of how something works is about as futile as getting them to say "GNU
> slash Linux".  So my take on the problem is to invoke the Principle of
> Least Astonishment and make account storage work the way users assume it
> does.  Copying accounts from one machine to another -ought- to be as
> simple as copying files in your Evolution data directory.
> 
> I propose we use key files.  Specifically a hierarchy of key file based
> GSettings objects, which I'll elaborate on.  I also propose we throw out
> the current EAccount and ESource classes (along with the group and list
> container classes) and unify them under a common framework.  The next
> release is called 3.0 so this is as good a time as any for a major API
> break in libedataserver.
> 
> For lack of a better word I'm reusing the term "source" to describe the
> key files, but with a slightly different definition.  A source is simply
> a node in a hierarchy of sources.  A source may describe a mail account,
> an address book, a calendar, a task list or memo list (or a combination
> thereof), or it may simply be a stub under which other sources are
> grouped.
> 
> The key files for these sources will live in two "sources" directories:
> a system wide directory for built-in sources and a user directory for
> custom sources.  For example:
> 
>     /usr/share/evolution-data-server-3.0/sources   # built-in sources
> 
>     $HOME/.local/share/evolution/sources           # custom sources
> 
> The user's "sources" directory will be monitored for changes, so adding
> or removing a custom source will be as simple as creating or removing a
> file in that directory.  Evolution will see it and respond accordingly.
> 
> In theory this should allow source creation tools such as the mail
> account capplet to be written as standalone programs that don't depend
> on Evolution APIs.  Such tools would just drop a properly formatted key
> file in the "sources" directory, and Evolution will see the new key file
> and automatically present the new source in its user interface.
> 
> I'm still designing the APIs for this, but I think I have the file
> format and GSettings mappings pretty much finished so I'll just talk
> about that.  More details about the API to follow.
> 
> A source's UID is the base name of its key file.  At minimum, the
> content of a key file consists of a [source] group conforming to the
> relocatable "org.gnome.Evolution.Source" schema, which defines the
> following keys:
> 
>   org.gnome.Evolution.Source
>   --------------------------
>   "name"     (string,  required)  The source's UTF-8 display name.
>   "parent"   (string,  optional)  The UID of the parent source, if any.
>   "backend"  (string,  optional)  The backend which handles the source.
> 
> The corresponding GSettings paths would be:
> 
>   /org/gnome/evolution/sources/<<uid>>/name
>   /org/gnome/evolution/sources/<<uid>>/parent
>   /org/gnome/evolution/sources/<<uid>>/backend
> 
> 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'
> 
>   2. Filename/UID: "on-ldap-servers"
> 
>      [source]
>      name='On LDAP Servers'
>      backend='ldap'
> 
>   3. Filename/UID: "google"
> 
>      [source]
>      name='Google'
>      backend='google'
> 
>   4. Filename/UID: "caldav"
> 
>      [source]
>      name='CalDAV'
>      backend='caldav'
> 
> The key file format is extensible.  The file can define additional
> groups, each with its own schema.  Each group is managed by a different
> GSettings instance, but they share a common key file backend.
> 
> This is how a source identifies itself as a mail account, a calendar, a
> task list, etc.  Plugins can even get in on the act, defining their own
> group and schema for, say, per-account mail notification options (as a
> hypothetical).
> 
> 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
> 
> The corresponding GSettings paths would be:
> 
>   /org/gnome/evolution/sources/system/name
>   /org/gnome/evolution/sources/system/parent
>   /org/gnome/evolution/sources/system/extensions/address-book/color
>   /org/gnome/evolution/sources/system/extensions/address-book/enabled
>   /org/gnome/evolution/sources/system/extensions/calendar/color
>   /org/gnome/evolution/sources/system/extensions/calendar/enabled
>   /org/gnome/evolution/sources/system/extensions/task-list/color
>   /org/gnome/evolution/sources/system/extensions/task-list/enabled
>   /org/gnome/evolution/sources/system/extensions/memo-list/color
>   /org/gnome/evolution/sources/system/extensions/memo-list/enabled
> 
> Hopefully now the mapping between key file groups and GSettings paths is
> clear so I don't have to write that out again.  :)
> 
> So the "system" source defines a built-in address book, calendar, task
> list and memo list, all named "Personal".  And notice how it doesn't
> give a value for "backend".  It defers to its parent source for that
> (on-this-computer -> backend='local').
> 
> For a mail account you would have a key file with a [source] group and
> an [extensions/mail] group.  All the properties of our current EAccount
> API would appear in the [extensions/mail] group.  In the interest of
> brevity I'll skip an example of that.
> 
> Backends can also define their own groups and schemas for storing
> settings that are specific to that backend.  Here's an off-the-cuff
> example of what a source describing a CalDAV calendar might look like:
> 
>   [source]                    # org.gnome.Evolution.Source
>   name='My Calendar'
>   parent='caldav'
> 
>   [extensions/calendar]       # org.gnome.Evolution.Source.Selectable
>   color='#e2f0d3'
>   enabled=true
> 
>   [extensions/caldav]         # org.gnome.Evolution.Source.CalDAV
>   host='my.caldav.provider'
>   user='mbarnes'
>   path='/dav/mbarnes/Calendar'
>   ssl=true
>   ...
> 
> (I'm leaning away from having URI keys, favoring instead URI components
>  as separate keys from which a complete URI string can be formed.)
> 
> Here's where the hierarchy concept gets powerful.  The source structure
> for a groupware account providing integrated mail, calendars, contacts
> (this is Exchange, GroupWise, perhaps someday Zimbra and Kolab, etc.)
> might be a top-level source with groups defining a mail account with
> server info and also any calendars or address books that you get by
> default on the groupware account.  Additional calendars or address books
> or public mail folders for you or even other users on the server could
> be implemented as child sources, such that disabling or deleting the
> top-level mail account source affects the entire subtree of sources.
> 
> This is getting a little hand wavy now because I've only just figured
> out the file format and groupware integration is a ways off.  But I hope
> you can kinda see where I'm going with this and recognize its value over
> what we have now.
Looks neat and clear :)

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