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