On Mon, Dec 19, 2011 at 4:08 PM, Patrick Ohly <[email protected]> wrote: > On Mo, 2011-12-19 at 15:49 +0100, Chris Kühl wrote: >> On Mon, Dec 19, 2011 at 3:24 PM, Patrick Ohly <[email protected]> wrote: >> > On Mo, 2011-12-19 at 15:21 +0100, Chris Kühl wrote: >> >> On Mon, Dec 19, 2011 at 12:26 PM, Patrick Ohly <[email protected]> >> >> wrote: >> >> > On Mo, 2011-12-19 at 11:02 +0100, Chris Kühl wrote: >> >> >> When looking into why the Session has a GetConfigs dbus method, I >> >> >> noticed that there are several dbus methods which are not documented >> >> >> in syncevo-session-full.xml. This includes Attach which is actually >> >> >> mention but not properly documented in that file. >> >> > >> >> > Good catch. >> >> >> >> So what is the reason for GetConfigs in the DBus Session API? It seems >> >> to be identical to Server.GetConfigs. >> > >> > It's just there for the sake of completeness. >> > >> >> This DBus method invokes the getConfigs method in ReadOperations. In >> turn, this calls Server::getDeviceList which requires BluezManager. >> I'd rather not have to create a new BluezManager in the Session sync >> process or cause the Session.GetConfigs to trigger a call to the >> Server's GetConfigs method (or it's peer-to-peer dbus equivalent). If >> it's, in fact, not really needed, is it ok if I drop this from the >> Session dbus api ...at least for now? > > Oh, now I understand the original question. GetConfigs() is available > for a session because it is always provided by ReadOperations, right? It > was never documented as a session method. So in that sense it can be > considered an implementation detail which can be removed. > > But why does the method have to be executed in the session process? > Isn't the caller talking to the main process who needs to dispatch calls > through to the background process? What I am aiming at is that the main > process could execute this particular method as if it had been invoked > on the server interface. >
As mentioned in the first of 3 steps outlining my plans for this work, I'm attempting to break the session apart from the server; decoupling it completely. This is a pain and has caused me to consider only running the sync in the separate process several times. However, I feel it would be much cleaner (but definitely not easier) if the session, along with its dbus api, lives in its own process. Ideally, the dbus api shouldn't change for consumers of the api, but if GetConfigs is not really needed or used then it'd make life easier to nix it. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
