Hello! In parallel to the D-Bus API discussion I continued with the reimplementation of the syncevo-dbus-server based on libgdbus and a pure C++ infrastructure. This involved a fair amount of experimentation and code refactoring, which is all visible in the history of the "dbus-api" branch. Before suggesting to merge the branch I'll clean it up via rebasing and merging of commits. Right now what matters is the latest revision. Comments inside it document the architecture and in particular the life cycle handling of the various objects (server, session, connection). There shouldn't be a need to go to the history to understand the current solution. At the moment, the server has a work queue to handle multiple session requests, tracks unexpected client disconnects and implements the methods and signals related to the object life cycles: Server.Connect(), Server.StartSession(), Connection.Close(), Session.Close(), Server.SessionChanged. Those who are interested (Yongsheng?), please have a look and and let me know whether the comments are sufficient to understand how the thing works. It's all in the syncevo-dbus-server.cpp file. The classes are declared at the top of the file, with the method implementations following at the end. This could be split into multiple files, but I don't really see the need for it because there won't be multiple users of these classes. Compile speed IMHO is not an issue. The next steps are: * Jussi: finalize the D-Bus GUI API spec, including full documentation * Patrick: provide stubs for the other new methods * Patrick: fully implement running a sync session via the Connection interface (includes Session status and progress handling) * Yongsheng (?): implement config handling Yongsheng, if I add stub calls first, then we can continue to edit the file at the same time and hopefully won't run into merge conflicts. -- 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.