On Mon, Dec 19, 2011 at 4:08 PM, Patrick Ohly <patrick.ohly(a)intel.com> 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 <patrick.ohly(a)intel.com> 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
> >> > 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
> >> >> in syncevo-session-full.xml. This includes Attach which is
> >> >> 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