[SyncEvolution] D-Bus bindings: C++ or C?

[Jussi Kukkonen]

Marcel Holtmann wrote:
> Hi Patrick,
> 
>> I'm having second thoughts about the decision that Jussi and I made back
>> in January about using dbus-glib as the main interface to D-Bus in the
>> syncevo-dbus-server. The main rationale at that time was that it is
>> readily available and a known quantity.
>>
>> However, after looking at some of the code that Jussi had to write to
>> make our C++ classes work as part of a D-Bus server I'm wondering
>> whether this advantage of dbus-glib is really worth it. Much of it is
>> manually written glue code between dbus-glib/GObject and C++.

Partial reason for the large amount of code was the decision to make the 
client side a C library. I notice that Josh has just backtracked his 
similar decision in carrick/gconnman because of the reasons you 
stated... On the other hand, the client code is pretty nice when using 
the library.

I had two concerns with dbus-c++ then (and I guess I still do):

1. maintenance: there are at least three forks right now and it seems at 
least two are quite incompatible.

2. completeness/reliability,
My expertise in C++ or (or D-Bus) is not deep enough to evaluate how 
complete or tested these bindings are.


> inside BlueZ, ConnMan, oFono etc. we are using libgdbus which is a nice
> and small helper library for writing D-Bus servers in C without any big
> extra bloat. We even duplicate the source in all projects to make it
> simpler for packages and integrators. I am not saying that this is the
> right solution for you, but you asked ;)

Thanks, that may make sense. It's just that dbus-glib was a known evil 
for me at the time... I've looked at connman and gdbus does look like a 
  nice and clean API at least from server POV.

However, I have to point out that from my GTK+ application POV a 
syncevolution-dbus-abstraction gobject is not bloat, it's a feature.

  - Jussi