[Evolution-hackers] Further thoughts on ESources

[Matthew Barnes <mbarnes redhat com>]

Now that my head's back into account management issues, I wanted to
brain storm about something that's been knocking around in my brain for
a few weeks.  Seeing how David Zeuthen implemented the Online Accounts
service I think has influenced my thinking.

Right now on the account-mgmt branch I've got this ESourceRegistry
singleton class which collects all the ESource objects in one place and
monitors the corresponding key files and the directory they live in for
changes.

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

However, every process -- be it the addressbook/calendar factories,
Evolution or any other client -- will need its own ESourceRegistry
instance and hence would be doing its own file monitoring.  The idea is
through file monitors all the processes are supposed keep their ESources
in-sync.

I think that approach would probably work in practice -- since ESource
contents will rarely change.  But it feels increasingly wrong to me from
an architectural viewpoint.

Consider this: the GNOME Online Accounts integration module I wrote
recently lives in Evolution, which is clearly the wrong place for it,
but we don't currently have a place for it in Evolution-Data-Server.
That means if you set up a Google account through Control Center, your
Google Calendar appointments will not show up in GNOME Shell calendar
until you start Evolution so that the "online-accounts" module can set
up ESources for you.

Proposal:

I think the key file management needs to be centralized in a new D-Bus
service, tentatively called "e-source-registry".  The ESourceRegistry
singleton class in client programs would then be a proxy for the D-Bus
service.  So we'd have a bit of a D-Bus hierarchy:


           evolution and other e-d-s clients
                     |      |      |
    e-addressbook-factory   |   e-calendar-factory
                      \     |     /
                    e-source-registry


The e-source-registry process would be extensible of course, with its
own set of dynamically loaded modules.

That would give the "online-accounts" module a more natural place to
live, and would help strip Evolution of its special E-D-S privileges,
making it closer to being just another E-D-S client, which I think has
always been the intent.

Moreover, it would give groupware extensions (Exchange, etc.) a place to
install modules that can monitor an account and keep local ESources in
sync with remote resources.  For example if a new calendar shows up on
an Exchange server (perhaps from the user doing stuff through the web),
the Exchange e-source-registry module could notice the change and define
a new ESource for that calendar.  All without ever starting Evolution.

I haven't worked out all the logistics or a D-Bus API yet, so this is
still a bit hand wavy.  But the new GDBus code generation tools in GLib
2.30 should make this fairly easy to set up.  It was for David when he
wrote GNOME Online Accounts.  And it feels like the right direction.

Once I get the branch building again, I think I'll spend a little time
playing with this idea and see if it pans out.

Comments?

Matthew Barnes