2012/3/20 Patrick Ohly <[email protected]>: > 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 have not begin that even. :) Is there something else you want to be done by me in this area? >> 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
