Re: [Evolution-hackers] Further thoughts on ESources

[Matthew Barnes <mbarnes redhat com>]

On Fri, 2011-08-26 at 07:39 +0200, Milan Crha wrote: 
> 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.

Yeah, maybe.  I think the bus name is more important than the process
name.  Currently we have:

   org.gnome.evolution.dataserver.AddressBook1
   org.gnome.evolution.dataserver.Calendar1

perhaps the new service would be named:

   org.gnome.evolution.dataserver.Sources0


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

Reconnect?  The usage pattern I envision for proxy object is to connect,
obtain all the sources somehow (details TBD), and then just listen for
the occasional add/remove/change signal.  If the proxy has to reconnect
and refresh its set of sources, it's trivial to filter out by UID the
sources it already knows about.

Point is, all the details should be hidden in the proxy object.  Should
be transparent to clients.


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

I think David added the code generation shortly after you wrote all that
out by hand.  I remember thinking of the irony when that landed.

We could look into using the code generation tools for 3.4 if you think
it's worth it.  Since it's in GLib now I don't think we'll get stuck in
the "generate once and it rots forever" trap like last time.