[Evolution-hackers] Merging the account-mgmt branch this weekend

[Matthew Barnes <mbarnes redhat com>]

This is a heads up that I will be releasing Evolution 3.5.2 and co. this
weekend and then merging the account-mgmt branches for E-D-S, Evolution,
and Evolution-EWS.  Evolution-MAPI will follow sometime after the merge.

The account-mgmt branch is an effort to overhaul how we manage account
information.  It solves some long-standing problems in the architecture
we've been using for the past decade, and hopefully makes accounts more
flexible so we can do new and interesting things we couldn't before.

I have documented much of the design decisions and progress over the
past 18 months in a thread on this mailing list entitled "Rethinking
Account Management" [1].

As this branch represents 18 months of largely non-peer-reviewed work,
I'm sure there's going to be bugs and regressions.  Just report them as
you find them and I'll try to be responsive.  My most immediate concern,
however, is that account migration works correctly.  Bugs can always be
fixed, but the migration code typically runs only once.  And if I botch
that we'll have a royal mess on our hands come Fall.


Here's a quick recap of the major changes:


* Account data will be removed from GConf and converted to plain text
  files which live in $HOME/.config/evolution/sources.  The file format
  will be an .ini-like syntax understood by GKeyFile, rather than XML.

  I have documented the new file format here:
  https://live.gnome.org/Evolution/ESourceFileFormat


* Clients will not access these files directly.  Instead, a new D-Bus
  service named "evolution-source-registry" is introduced to serve these
  files to clients.  Clients will access ESources via a new client-side
  class named ESourceRegistry. 

  ESourceRegistry is intended to be a singleton instance used by all
  E-D-S clients as well as our own ECal/EBook factory services.

  The "evolution-source-registry" service (or just "registry" service)
  has a few other responsibilities, detailed below.


* Authentication attempts are now coordinated between backends and the
  "registry" service.  The service queues all backend requests, handles
  keyring lookups and password prompting, and securely feeds passwords
  to backends to test. 

  This takes client applications completely out of the authentication
  loop.  EClient no longer has an "authenticate" signal.

  This means "headless" E-D-S clients with no main window of their own
  like evolution-alarm-notify and gnome-shell-calendar-server, as well
  as E-D-S clients which don't even link to GTK+, can access calendars
  and address books as easily as applications like Evolution and GNOME
  Contacts which have historically handled authentication themselves.

  The "registry" service uses GcrSystemPrompt [2] to display a system
  modal password prompt.  If running a GNOME Shell session, GNOME Shell
  takes over and displays the prompt as a fancy Javascript-style dialog.
  This is the same mechanism the gnome-keyring-daemon now uses to prompt
  users for keyring passwords.

  ECredentials and e-passwords.c are now deprecated.


* The "registry" service is extensible through EExtension the same way
  Evolution is.  I've already written a few extension modules for the
  service:

    online-accounts

    Integrates with GNOME Online Accounts.  Basically takes over for
    Evolution in synchronizing E-D-S sources with GOA accounts.  You
    no longer have to start Evolution for GOA accounts to be noticed.

    cache-reaper

Deletes abandoned cache directories. The reaper scans directories
shortly after the service starts up and then once every 24 hours.
It lets newly-orphaned directories age a few days before reaping
them, in case the account deletion was accidental or cached data
needs to be salvaged. It does not touch data directories. 

    google-backend / yahoo-backend

    These are "collection" backends (described below) for Google and
    Yahoo! accounts.  These are functional but not yet complete.


* The "registry" service, through its extension framework, hosts a new
  kind of backend called a "collection" backend.  The term "collection"
  is borrowed from WebDAV nomenclature.  A collection backend's job is
  to manage a collection of ESources as a single account.  Usually this
  involves querying a remote server for private and shared data sources,
  setting up equivalent ESource instances to serve as proxies, and then
  keeping the collection synchronized with the remote server.

  The idea is if you create, say, a new calendar on a groupware server,
  the collection backend for that server is supposed to notice the new
  calendar and assemble an equivalent ESource for it, which is then
  exported over D-Bus and all active E-D-S clients see it immediately.

  I've really only just begun to implement collection backends.  There's
  a lot more work to be done here to fully realize what I have in mind.


* There will be API breakage at all levels of Evolution-Data-Server, but
  most severely in libedataserver.  ESourceList, ESourceGroup, EAccount,
  and EAccountList are all gone, replaced by ESourceRegistry.

  ESource still exists and is conceptually the same as before, but its
  API is completely different now.  It's basically a glorified key file
  interface with a few asynchronous D-Bus methods.

  ESource also now handles mail accounts, unifying at last all account
  management under one API.

  The new libedataserver and libebackend APIs are documented here:

  http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/

  http://mbarnes.fedorapeople.org/account-mgmt/docs/libebackend/


* The account editor and the calendar and address book configuration
  dialogs have been rewritten from scratch.  They no longer use EConfig,
  nor even EPlugin at all.  They are now extended through EExtensions.

  Now that the config editors are liberated from EPlugin, I'd like to
  take a serious look at moving them to Evolution-Data-Server.  I still 
  need to figure out the details there.


* Lastly, the test suite in Evolution-Data-Server is pretty borked at
  the moment.  I hope to get the test suite operational again by 3.6.
  Now that account information is stored in XDG-compliant directories,
  we should be able to create a much nicer and fully automated test
  harness that doesn't risk interfering with your own accounts.


I have several patches prepared already for other projects to help them
quickly adapt to the API breaks.  I'll also be blogging about this today
or tomorrow.

Matthew Barnes 


[1] Thread starts here:
https://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html

[2] http://developer.gnome.org/gcr/unstable/GcrSystemPrompt.html