On Mon, 2011-12-05 at 12:12 +0100, Chris Kühl wrote: > On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <[email protected]> wrote: > > Here are some requirements for "sync in forked process": > > * should be disabled when running outside of the D-Bus daemon > > (syncevolution command line in non-daemon mode, client-test > > testing) > > This seems pretty straightforward because when in non-daemon mode none > of the src/dbus/server code is touched anyway. I'm hoping to disturb > the code in src/syncevo as little as possible. But I've not touched > src/syncevolution.cpp much so maybe I'm missing something.
Yes, this should work. libsyncevolution (aka src/syncevo) communicates with the front-end via ConfigUserInterface (implemented differently for command line and D-Bus server) and several virtual methods in SyncContext (display*(), for example displaySyncProgress()). In particular the password request mechanism is very convoluted. I haven't written that part myself and each time I look at it, I need to trace through the various methods before I can piece together how they interact. I suspect that this will have to be cleaned up. Perhaps SyncContext should be parameterized with instances of ConfigUserIterface and SyncUserInterface (new class, would hold the display* functionality) instead of deriving from it? > > * interactive password requests through D-Bus must continue to > > work > > * abort/suspend requests via D-Bus must work > > * the forked process should shut down cleanly, so that "valgrind > > --follow-child=yes --leak-check=yes" provides sane results (the > > forked process in a local sync currently fails to do that, > > because it is forked in a less controlled environment and > > therefore just calls _exit()) > > Using fork then exec should mostly relieve us of this issue. Agreed. > > * logging: > > * the main syncevo-dbus-server process should use syslog > > logging for its own messages, without redirecting > > stdout/stderr > > * the forked process should start redirecting > > stdout/stderr into the normal logging mechanism (so that > > library error messages are visible when running the > > syncevolution command line as client of the D-Bus server > > and, later, they appear in log files) and switch to a > > session log when the session is ready > > > > I plan to do this work in 3 steps: > > 1) The first step, which I've started, is to decouple the session and > server from each other and also modify objects that require both the > session and server objects as needed. Once this is done the server > should function as it does now and all tests should pass in order to > move on to step 2. > 2) Move session into separate binary using a one-to-one dbus > connection for communicating between the 2 processes. At this stage > only one session is run at a time and all tests should pass as before. Please try to keep this flexible. I'd like to use the separate binary not only for running sessions, but also for monitoring local and remote databases for changes. The main D-Bus server then would get a signal that a specific config requires a sync run and would kick of that operation when suitable. > 3) Enable running multiple concurrent sync sessions. At this stage > we'll probably need to add/modify some tests in order to deal with the > new functionality. Multiple concurrent sync sessions are a can of worms, so careful here. The main question is: which sync sessions are allowed to run in parallel? For example, syncing against the same local database in parallel is asking for (unnecessary) trouble. If the instance controlling sync sessions wants to prevent that, how does it identify the "same database"? Backend "foo" + database "xxx" might access the same data as backend "bar" + database "yyy" (in theory, at least). The original idea was that each database would only be configured once, so that source "addressbook" in context "@default" would be unique. But this has never been enforced (it can't be, due to the problem above) and has not been clearly documented either. -- 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
