On Tue, 2012-03-20 at 12:21 +0100, Krzesimir Nowak wrote: > 2012/3/20 Patrick Ohly <[email protected]>: > > On Tue, 2012-03-20 at 11:46 +0100, Krzesimir Nowak wrote: > >> [ERROR syncevo-dbus-helper 00:00:00] sending message to child failed: > >> org.freedesktop.DBus.Error.UnknownMethod: No such interface > >> `org.syncevolution.localtransport.child' on object at path / > >> > >> Looks like something is racy. > > > > Probably the same issue as for > > syncevo-dbus-server<->syncevo-dbus-helper, but now between > > syncevo-dbus-helper<->syncevo-local-sync. See my email about not always > > using delayed message processing in ForkExec - syncevo-local-sync still > > starts processing right away, because its call to ForkExec was not > > updated yet. > > > > In my current work branch I have merged your ForkExec patch without the > > "delayed = false" parameter. > > Ah, right. I thought that you already did that for > concurrent-sync-pohly-delayed-dbus upon which my work is based. > > I am now wondering if I should now try moving some common code from > session resource and connection resource to base class.
Please stop for now. You'll end up duplicating work. > I read that > you are trying to move connection stuff to server and that would end > with not using sync-helper for it, that is - connection resource > itself would disappear I think. Exactly. Connection and AutoSyncManager depend on common state information (presence, session history). That state information should stay in the syncevo-dbus-server together with the main logic in these classes, to avoid constantly calling out to some helper. -- 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
