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
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
