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?

Cheers,
Chris
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to