Re: [Evolution-hackers] New 'eclient' branch in eds

[Milan Crha <mcrha redhat com>]

On Fri, 2011-04-29 at 07:24 -0400, Matthew Barnes wrote:
> On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote: 
> > There was just a little problem with ECalView, which had 'client'
> > property, which is referring to ECal, instead of ECalClient, and I was
> > forced to "invent" different name for it. But after a bit of sleeping
> > and small thinking I might be wrong on this point too, as it should be
> > easy to define EBookClientView/ECalClientView and keep old
> > EBook/CalView-s as they are, at least their public API.
> 
> Cool.  That was my initial thought too but didn't know how much extra
> work that would be.

	Hi,
so I did. There are new EBookClientView/ECalClientView defined. They use
exactly the same interface, with same signal names defined and their
signatures, the only difference is function naming and the GDBus object
used at the background. Consider it as the first step on the "merge
common code of cal/book factory and cal/book view", which will make it
easier to adapt to such change in the future.

As I mentioned earlier, factories and views, all concrete
implementations and gdbus stubs can be merged and mostly reused between
calendar and addressbook factories. The only issue is compilation order
(some file placement restructuralization will be needed, for example to
be able to define EClientView and have it available in e-client.h, but
also in e-cal-client.h/.c and e-book-client.h/.c for exact
implementation).

I noticed one difference between factories, recently. The calendar
factory keeps running all backends for all the time the factory is run
(since the backend is opened for the first time), even when no consumers
exist. The addressbook factory frees the backend as soon as the last
client is gone. Each has its advantages for sure. I'm mentioning it here
only to be aware of such difference and to anyone going further with the
merge idea to pick the better of them. I'm not sure which it is, though.

I'm not going any further in this merging effort, because I do not think
it breaks anyhow the EClient idea as is. The merging can be postponed to
any time later, even for 3.4 or beyond, from my point of view.
	Bye,
	Milan