How to use org.freedesktop.DBus.ObjectManager?

[wpd]

I am trying to use this library to implement a Bluetooth Low Energy (BLE) peripheral with bluez. (Perhaps you know of somebody who has already done this... I'd be happy to go pester them instead of you :-) ) And, I don't really know what I'm doing yet. So, I'm in the stage of "ask lots of questions and read lots of web pages".

According to gatt-api.txt:

BlueZ requires that all objects that belong to a GATT service be grouped under a D-Bus Object Manager that solely manages the objects of that service. Hence, the standard DBus.ObjectManager interface must be available on the root service path.

It seems to me then, that I need to create an sdbus-cpp top level object and enable the ObjectManager on it, perhaps by calling something like:

auto topLevel = sdbus::createObject(*connection, "/com/example");
topLevel.addobjectManager();

and then, to create the object for the service, I would:

auto myService = sdbus::createObject(*connection, "/com/example/service0");

but how do I associate the myService object as something that is managed by the topLevel object? Does sdbus-cpp do that automatically for me just because they share the same base path (/com/example), or is there an addManagedObject() API function (which I can't find) which I should call to associated myService with topLevel?

Does my question make sense? Often, a question that makes no sense, is an indicator that the person asking the question has no idea what he is talking about. That is absolutely the case now.

Thanks for any help or tips you can provide.

--wpd

[sangelovic]

Hi @wpd,

... the person asking the question has no idea what he is talking about. That is absolutely the case now.

That's OK, I fully understand :) And your question makes sense :)

but how do I associate the myService object as something that is managed by the topLevel object?

As far as I remember, the association is simply inferred from the object path. So, in your example, you should automatically have an item for /com/example/service0 object in the output of topLevel's GetManagedObjects call.

Btw., I suggest, unless you have counter-reasons, that you use the highest-level API of sdbus-c++. Just get hold of the IDL XML of the service you're talking to (using dbus-introspect cmd line tool, for example), and have the proxy classes generated from that by sdbus-c++-xml2cpp tool, and use these. It will make your code simpler and more expressive. And in this specific case of yours, it will automatically enable object management on your /com/example D-Bus object when inherit from ObjectManager_adaptor interface. Look into the tutorial for how to use high-level, generated API. And also look in the integration tests code, for examples.

[wpd]

As far as I know (and what I have seen in other code), I have to create the IDL. The other code I have seen creates it programmatically. I was hoping to learn that sdbus-cpp offered me a way around that, thinking that it seemed sort of primitive (compared to what I have seen with Python examples). Someday I might know what I'm talking about, but not today :-)

--wpd

[riuriuriu]

I think the same problem is described in #139 . The ObjectManager_adaptor should IMO be changed so that you can pass an object path or tree. I'm using a local patch-set to work around this but didn't have the time yet to properly update the tests and prepare a pull request.

[dleeds-cpi]

Hi @riuriuriu I read #139 and that sounds like a case of incorrect usage of ObjectManager_adaptor. What I have described is a separate issue relating to practical usage of ObjectManager_proxy.

[riuriuriu]

However, normal usage of the ObjectManager is to subscribe to InterfacesAdded signals using either no path match, or a 'path_namespace' match rule that matches everything under the service's root path, so you can see new objects being created and then instantiate proxies for them.

That sounds like an abuse of the org.freedesktop.DBus.ObjectManager interface.

The object manager interface should be implemented on the root of a tree or sub-tree of managed objects. That root path will send the signal org.freedesktop.DBus.ObjectManager.InterfacesAdded (OBJPATH object_path, DICT<STRING,DICT<STRING,VARIANT>> interfaces_and_properties). There is the argument object_path.

On the proxy side, one can set it's path to the root path where org.freedesktop.DBus.ObjectManager is implemented. Your new objects are provided by object_path. No need for match rules.

Check out the spec of org.freedesktop.DBus.ObjectManager.