Log in

Major Evolution-Data-Server API breaks about to land

I mentioned in my previous blog post a few months ago that I've been overhauling Evolution-Data-Server's account format and APIs.  I've been doing all this work on a very long-running branch (18 months old now!) which was not ready in time for GNOME 3.4.  But it's ready now, and I'll be merging it this weekend just after the Evolution 3.5.2 tarballs are released.

I'm announcing this to a wide audience because the API breaks are going to affect a number of other projects in the GNOME community and perhaps beyond.  I already have patches prepared for several key GNOME components, and I stand ready to assist any other projects which will need to port their code to the new Evolution-Data-Server APIs.  Please contact me if you maintain one of these projects so I can help make the transition as smooth as possible. (mbarnes@redhat.com or #evolution on IRC).

In short, Evolution-Data-Server will migrate account data from the XML blobs we've historically stuffed into GConf to plain text files which live under the XDG-compliant $XDG_CONFIG_HOME directory.  Evolution-Data-Server will also introduce a new D-Bus service to serve these account files to client programs and to take over certain account management responsibilities so that Evolution-Data-Server becomes more of an autonomous desktop service that does not rely so heavily on Evolution.

I've written a fair amount of documentation, so just to get the links out of the way...
Immediate benefits to users and to GNOME are:
  • Much easier to backup account data or copy it to other machines.  Having account data locked in a configuration database makes this pretty painful at present.  This has been an ongoing problem for at least as long as I've been involved with Evolution (circa 2006).  Evolution-Data-Server will monitor the user directory containing the account files, which means restoring an account is simply a matter of dropping files into that folder.  Evolution-Data-Server will notice the new files and (assuming they're valid) activate them immediately without having to restart any programs.
  • The new D-Bus service will centralize interactive authentication prompts.  This means client programs will no longer have to deal with authentication at all.  Internally, the new D-Bus service will use GcrSystemPrompt to show a system-modal password prompt whenever a mail, calendar or address book backend needs to authenticate and a password is not readily available.  In a GNOME Shell session, GNOME Shell will take over and display a dialog window consistent with the shell's overall look and feel.
  • The new D-Bus service will monitor GNOME Online Accounts and automatically add or delete equivalent Evolution-Data-Server accounts.  Previously Evolution handled this, which unfortunately meant Evolution had to be already running or at least started for new Google accounts to be noticed and propagated to services like the GNOME Shell calendar.  That issue is now solved.
  • As part of this effort I've also converted Evolution-EWS to the new Evolution-Data-Server APIs and have added support for GNOME Online Accounts' new Exchange option.  This is a major feature for GNOME 3.6.
The new account management system also opens the door to all kinds of cool new enhancements to Evolution and Evolution-Data-Server.  I have lots of ideas and could easily spend another year chasing them all, but the order of the day is to get this branch finally merged so we can shake out the bugs and help other projects adapt in time for GNOME 3.6.



I hope it is so wonderful as it sounded. Finally no more disappearing addressbooks.


Just curious, are there hurdles to using GSettings/dconf to replace the xml blobs? In any case, plain text is waaay better than xml-stuffed-in-gconf.

Since it predates my involvement, best I can figure is GConf was chosen to host the account data because of its convenient inter-process change notifications. Using GConf this way was a hack to begin with, and nowadays there's better ways. We have D-Bus.

dconf is another configuration database like GConf, and for account data which needs to be highly mobile, dconf carries the same problems as GConf. Acually it makes them worse because where GConf at least split desktop settings into separate XML files, dconf's on-disk format is a single binary blob with all your desktop settings mixed together.

I have nothing against dconf. It has its uses. This isn't one of them.


Great work! Thanks for all the efforts you are putting in Evolution and this particular task, it is a huge work, and greatly appreciated :)
Thanks, that's nice to hear. :)

I'm looking forward to just fixing bugs for a little while. This turned out to be a herculean task and nearly did me in.

June 2012

Powered by LiveJournal.com