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. -- 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
