Hi All, On 11/30/2015 08:16 AM, Andrejs Hanins wrote: > Hi, > > On 11/29/2015 04:04 AM, Ryan Kuester wrote: >> Hello everyone, >> >> When registering a GATT service via the D-Bus API, bluez-5.36 >> seems to expect the objects returned by the service's >> GetManagedObjects method to include the service object itself, >> the root of the managed object tree. Indeed, the included >> test/example-gatt-server behaves this way[1]. >> >> However, the D-Bus Specification seems to say an ObjectManager >> should return the objects *under* the ObjectManager, i.e., only >> the service's children---characteristics and descriptors. This >> reading of the specification is in agreement with the >> ObjectManager implementations in GDBus and Python's txdbus (I >> didn't check other implementations). >> >> bluez's disagreement with the standard causes pain when trying to >> use the ObjectManager implementations in the libraries, because >> they don't return the ObjectManager itself, the service object, >> as bluez expects. E.g., in txdbus, it's impossible to implement >> the ObjectManager interface in application code (to get the >> non-standard behavior) without patching the library. >> >> Does the expectation that the service object appear in the >> GetManagedObjects result look like a disagreement with the D-Bus >> standard to anyone else? > > The same to me. I'm using Glib/Glibmm to export GATT services and > Glib D-Bus code asserts in debug mode when object path matches > with object manager path. I'm currently blindly ignoring this, cause > it doesn't seems to cause any functionality problems in release code. I was also bitten by that assert. I assumed it was a bug so I wrote a bug report about it: https://bugzilla.gnome.org/show_bug.cgi?id=758393 But after this discussion I'm not sure if it is a bug. Regards /Jonas > >> >> Thanks for all the good work on bluez, >> -- Ryan >> >> >> P.S. A possibly related issue is causing tools/gatt-service.c to >> fail. It implements the ObjectManager interface on the root path >> of the bus connection, rather on the service object. Perhaps this >> indicates the service object *was* under a separate ObjectManager >> in past versions, and this evolved into the current discrepancy >> now that the service object *is* the ObjectManager. >> >> 1: text/example-gatt-server implements the ObjectManger >> interface directly, making it easy to include the service object >> in the GetManagedObjects result, even if returning the object is >> nonstandard behavior, because the example is is written using >> dbus-python, which doesn't provide help implementing the >> ObjectManager interface. >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
