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

[Milan Crha <mcrha redhat com>]

On Thu, 2011-04-28 at 11:59 -0400, Matthew Barnes wrote:
> On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote: 
> > You obviously face of a circular dependency, so it's not doable in a
> > clean way. Also because EClient is in libedataserver, EBookClient in
> > addressbook/libebook and similarly ECalClient in calendar/libecal. Both
> > descendants link to libedataserver... Having another
> > register_client/unregister_client function will make things only less
> > clear for readers (like if one tries to follow signal handlers by
> > reading the code.
> 
> Way to douse me with a bucket of cold water there.  :)
> 
> You're right about the library dependencies.  That does kinda put a
> bullet in unifying the "new" function.  I agree a type registration
> system is overkill for a mere two GTypes.
> 
> Still, is there any value in having such an enum defined in e-client.h?
> 
> I cited one benefit in consolidating my "get_default_source" functions,
> but that alone is not really compelling.  Are there other use cases?

Yes, when I was changing server side data-views for book and cal, then
if turned out that the D-Bus API is exactly the same except of the
DBUS_PROXY_NAME and book/cal strings in a file.

Thus having type param for both factories too, though for book unused,
may clean the code very nicely, forcing us to exactly one implementation
of base EGDBusFactory, EGDBusView, EDataFactory, EDataView and subclass
these to EGDBusBookFactory, EGDBusCalFactory, ...  and changing only
really minimum on them. Basically the effort which started Travis
Reitter in his eds branches.