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 > [email protected] > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
