On Fri, Jul 31, 2015 at 10:30 AM, Adam Moore <adam.moore@xxxxxxxxxxxxxxxxx> wrote: > I ran into this as well when trying to build a an external service with > GLibıs GDBusObjectManagerServer. As I was highly motivated not to rewrite > what I had, I have a little patch that relaxes the unwritten expectation, > but it comes at the expense of being unable to enforce that > characteristics reside under the service object. (I think the proxy > callback orderings are not guaranteed) However, it does allow the service > and characteristics to reside anywhere in the ObjectManager hierarchy. > > Iıll pass it along in case it helps accelerate a real fix, and perhaps it > can unblock someone in the meantime. I ran into a similar problem with GLib, and ended up reluctantly replacing my use of GDBusObjectManagerServer with a hand-coded implementation (except for the signals) of the ObjectManager interface that was exported on the same object path as the org.bluez.GattService1 skeleton via g_dbus_interface_skeleton_export(): https://git.iotivity.org/cgit/iotivity/tree/resource/csdk/connectivity/src/bt_le_adapter/linux/service.c#n213 -Ossama -- 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
