Re: [Evolution-hackers] Further thoughts on ESources

[Milan Crha <mcrha redhat com>]

On Thu, 2011-08-25 at 12:46 -0400, Matthew Barnes wrote:
> 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.

	Hi,
sounds good. One thing for a process name, it would be better to call it
evolution-source-registry, because Chen mentioned similar for factories
as well, but we never took a consensus on it and thus their name was
never changed.

> I haven't worked out all the logistics or a D-Bus API yet, so this is
> still a bit hand wavy.

One question comes on my mind: what will consumers do if the registry
process crashes? As long as you want to make it extensible, and the
example of exchange extension of doing stuff on a server, then it can
sometime result in a crash for sure. And seeing a flood panic on all
consumers might be sort of fun.

> 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.

Pity I didn't notice existence of the GDBus code generation tool before
I wrote all the templates for GDBus calls by hand. Though with all those
macros it seems to me like easier to read, if anyone would ever like to
read it. ;)
	Bye,
	Milan