Hi Adam, On Fri, Jul 31, 2015 at 11:00 AM, Adam Moore <adam.moore@xxxxxxxxxxxxxxxxx> wrote: > Ossama, thanks for sharing - I didn¹t have the heart to go down that path > :) Nice to have that solution available too. Ha! Believe you me, I preferred not going down this path since it basically reinvents the wheel. but I didn't have much choice at the time since I needed to get something out the door that didn't rely too heavily on upstream patches being merged. > Just a thought - since the Characteristic objects must provide their > service path via DBus Property, forcing their paths to be children of the > service path may be redundant, unless some logic is planned to be based on > the structure of the OM tree in the future. Agreed. In this case, I just followed the convention found in the example hierarchy described in the "GATT Manager Hierarchy" section in the BlueZ doc/gatt-api.txt document, as well as the hierarchy found in the BlueZ test/example-gatt-server Python code. Going with this hierarchy also mimics the GATT service hierarchy described in the Bluetooth spec. Thanks! -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
