[SyncEvolution] syncevo-dbus-server reimplementation
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.