Hello! 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++. I bet it would be a lot easier to solve this problem with dbus-c++. Except that it isn't part of most (all?) distros and much of the development takes place outside of the main project, with no recent official release... Another problem is lack or insufficient support for asynchronous method calls. Some branches of dbus-c++ might have it. This would be a deal-breaker, because we need that feature. So anyway, here's my question to Jussi: how much work is it really to implement the D-Bus API? Question to packagers: would you mind if we bundled a version of dbus-c++ with our source until some official release makes it into the distros? Any other alternatives? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
