[Evolution-hackers] GSettings Hackfest + Account Storage

[Matthew Barnes <mbarnes redhat com>]

I signed myself up for the GSettings Hackfest coming up in April [1].
It's being held in Boston so I have no excuse not to go.

My goal is to help validate the dconf/GSettings design by making
Evolution an early adopter.  The impetus for my EShellSettings design in
2.29 was to help make the transition from GConf to GSettings transparent
to the rest of the app, so I'm eager to prove this.

A secondary goal is to find a saner solution for account settings
storage.  I think there's universal agreement that our XML blobs are an
abuse of GConf and need to die, but I'm torn on which direction to take.

One the one hand, GSettings appears to solve many of GConf's
shortcomings that led to the XML blob approach in the first place.  In
particular, GSettingsList was specifically designed to hold things like
structured account settings.

On the other hand, users clearly expect to be able to move accounts by
simply copying files under ~/.evolution.  Having to deal with a settings
daemon introduces unexpected and unnecessary complexity for users, and
no amount of FAQ literature, automated backup/restore solutions, or
repeated guidance on IRC and the mailing list seems to stick.  So I
think we should cater to this expectation.

In recent months I've been seriously considering moving EAccount and
ESource settings out of GConf entirely and storing them as key files --
one key file per account or source, similar to .desktop files.  It would
solve the XML blob issue, and it would make Evolution accounts much more
portable.  Change notification and coordination between multiple clients
would be an issue to solve, however.

In talking this over with Ryan Lortie, he mentioned GSettings will
support a key file backend.  I need to research this more in-depth, but
it sounds like that could potentially be a good solution for account
settings: centralized access + change notification + a highly readable
and portable storage format.

Once I find time I'll be starting yet another branch to try and flesh
out some of these ideas, and pave the way for GSettings.

Matthew Barnes


[1] http://live.gnome.org/Hackfests/GSettings2010