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