The GATT service DBus interface currently requires that services
implement the following interfaces:
- org.freedesktop.DBus.ObjectManager
- org.freedesktop.DBus.Properties
- org.bluez.GattService1
An unwritten expectation is that the ObjectManager's GetManagedObjects
method should include the object itself in its return value. However,
the spec for GetManagedObjects states otherwise.
This currently works only because gdbus violates the spec.[1] Until
today, systemd's sd-bus library was compliant with the spec and thus
behaved differently from gdbus, making it impossible to use sd-bus with
bluez.[2]
I agree with Lennart's proposal that the best course of action is to
fix the spec, not the implementations. This would mean that no change
is needed for bluez (other than perhaps some documentation). However, I
wanted to raise awareness of this problem in case:
1. there is strong opposition to this proposal
2. others run into the same problem I did
[1] https://bugs.freedesktop.org/show_bug.cgi?id=91283
[2] https://github.com/systemd/systemd/commit/92d16a53e385781a55d9231d9
f8f89c1747ab0e4
DQoNCk9uIDcvMzEvMTUsIDEyOjQ1IFBNLCAiT3RobWFuLCBPc3NhbWEiIDxvc3NhbWEub3RobWFu
QGludGVsLmNvbT4gd3JvdGU6DQoNCj5IaSBBZGFtLA0KPg0KPk9uIEZyaSwgSnVsIDMxLCAyMDE1
IGF0IDExOjAwIEFNLCBBZGFtIE1vb3JlDQo+PGFkYW0ubW9vcmVAc2F2YW50c3lzdGVtcy5jb20+
IHdyb3RlOg0KPj4gT3NzYW1hLCB0aGFua3MgZm9yIHNoYXJpbmcgLSBJIGRpZG6p9nQgaGF2ZSB0
aGUgaGVhcnQgdG8gZ28gZG93biB0aGF0DQo+PnBhdGgNCj4+IDopICBOaWNlIHRvIGhhdmUgdGhh
dCBzb2x1dGlvbiBhdmFpbGFibGUgdG9vLg0KPg0KPkhhISAgQmVsaWV2ZSB5b3UgbWUsIEkgcHJl
ZmVycmVkIG5vdCBnb2luZyBkb3duIHRoaXMgcGF0aCBzaW5jZSBpdA0KPmJhc2ljYWxseSByZWlu
dmVudHMgdGhlIHdoZWVsLiBidXQgSSBkaWRuJ3QgaGF2ZSBtdWNoIGNob2ljZSBhdCB0aGUNCj50
aW1lIHNpbmNlIEkgbmVlZGVkIHRvIGdldCBzb21ldGhpbmcgb3V0IHRoZSBkb29yIHRoYXQgZGlk
bid0IHJlbHkgdG9vDQo+aGVhdmlseSBvbiB1cHN0cmVhbSBwYXRjaGVzIGJlaW5nIG1lcmdlZC4N
Cj4NCj4+IEp1c3QgYSB0aG91Z2h0IC0gc2luY2UgdGhlIENoYXJhY3RlcmlzdGljIG9iamVjdHMg
bXVzdCBwcm92aWRlIHRoZWlyDQo+PiBzZXJ2aWNlIHBhdGggdmlhIERCdXMgUHJvcGVydHksIGZv
cmNpbmcgdGhlaXIgcGF0aHMgdG8gYmUgY2hpbGRyZW4gb2YNCj4+dGhlDQo+PiBzZXJ2aWNlIHBh
dGggbWF5IGJlIHJlZHVuZGFudCwgdW5sZXNzIHNvbWUgbG9naWMgaXMgcGxhbm5lZCB0byBiZSBi
YXNlZA0KPj5vbg0KPj4gdGhlIHN0cnVjdHVyZSBvZiB0aGUgT00gdHJlZSBpbiB0aGUgZnV0dXJl
Lg0KPg0KPkFncmVlZC4gIEluIHRoaXMgY2FzZSwgSSBqdXN0IGZvbGxvd2VkIHRoZSBjb252ZW50
aW9uIGZvdW5kIGluIHRoZQ0KPmV4YW1wbGUgaGllcmFyY2h5IGRlc2NyaWJlZCBpbiB0aGUgIkdB
VFQgTWFuYWdlciBIaWVyYXJjaHkiIHNlY3Rpb24gaW4NCj50aGUgQmx1ZVogZG9jL2dhdHQtYXBp
LnR4dCBkb2N1bWVudCwgYXMgd2VsbCBhcyB0aGUgaGllcmFyY2h5IGZvdW5kIGluDQo+dGhlIEJs
dWVaIHRlc3QvZXhhbXBsZS1nYXR0LXNlcnZlciBQeXRob24gY29kZS4gIEdvaW5nIHdpdGggdGhp
cw0KPmhpZXJhcmNoeSBhbHNvIG1pbWljcyB0aGUgR0FUVCBzZXJ2aWNlIGhpZXJhcmNoeSBkZXNj
cmliZWQgaW4gdGhlDQo+Qmx1ZXRvb3RoIHNwZWMuDQoNClllYWgsIEkgdXNlZCB0aGUgc2FtZSBz
dHJ1Y3R1cmUgaW4gbXkgaW1wbGVtZW50YXRpb24gLSB0aGF0IHdhcyByZWFsbHkNCm1vcmUgb2Yg
YSBub3RlIGZvciB0aGUgbWFpbnRhaW5lcnMgdGhhdCBpZiB3ZSBjYW4gbGl2ZSB3aXRob3V0IGEg
c3RyaWN0DQpzdHJ1Y3R1cmUsIGl0IG1pZ2h0IHNpbXBsaWZ5IHRoZSBmaW5hbCBmaXguDQoNCj4N
Cj5UaGFua3MhDQo+LU9zc2FtYQ0KDQoNClN0YXRlbWVudCBvZiBDb25maWRlbnRpYWxpdHkNCg0K
VGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBh
cmUgY29uZmlkZW50aWFsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vl
LiBUaGUgaW5mb3JtYXRpb24gbWF5IGFsc28gYmUgbGVnYWxseSBwcml2aWxlZ2VkLiBUaGlzIHRy
YW5zbWlzc2lvbiBpcyBzZW50IGluIHRydXN0LCBhbmQgdGhlIHNvbGUgcHVycG9zZSBvZiBkZWxp
dmVyeSB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz
IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgYW55IHVzZSwgcmVwcm9kdWN0aW9uIG9yIGRpc3NlbWlu
YXRpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91
IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlm
eSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBvciBhdCA1MDguNjgzLjI1MDAgYW5kIGRlbGV0
ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55Lg0KDQo=
Hi Adam,
On Fri, Jul 31, 2015 at 11:00 AM, Adam Moore
<[email protected]> 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
Ossama, thanks for sharing - I didn?t have the heart to go down that path
:) Nice to have that solution available too.
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.
On 7/31/15, 10:47 AM, "Othman, Ossama" <[email protected]> wrote:
>On Fri, Jul 31, 2015 at 10:30 AM, Adam Moore
><[email protected]> 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
Statement of Confidentiality
The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any.
On Fri, Jul 31, 2015 at 10:30 AM, Adam Moore
<[email protected]> 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
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.
-Adam
On 7/31/15, 10:18 AM, "[email protected] on behalf of
Nathaniel McCallum" <[email protected] on behalf of
[email protected]> wrote:
>So it appears that our initial analysis was incorrect. In fact, all the
>dbus libraries behave the same. However, the Bluez GATT interface (and
>perhaps others) expects ObjectManager to behave incorrectly. Similarly,
>the Bluez test code contains a bug in its ObjectManager implementation.
>The offending line is here:
>http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-serv
>er#n91
>
>ObjectManager. GetManagedObjects() MUST NOT return itself in the set of
>returned children. The GATT interface needs to be updated to match this
>expectation.
>
>----- Original Message -----
>> The GATT service DBus interface currently requires that services
>> implement the following interfaces:
>> - org.freedesktop.DBus.ObjectManager
>> - org.freedesktop.DBus.Properties
>> - org.bluez.GattService1
>>
>> An unwritten expectation is that the ObjectManager's GetManagedObjects
>> method should include the object itself in its return value. However,
>> the spec for GetManagedObjects states otherwise.
>>
>> This currently works only because gdbus violates the spec.[1] Until
>> today, systemd's sd-bus library was compliant with the spec and thus
>> behaved differently from gdbus, making it impossible to use sd-bus with
>> bluez.[2]
>>
>> I agree with Lennart's proposal that the best course of action is to
>> fix the spec, not the implementations. This would mean that no change
>> is needed for bluez (other than perhaps some documentation). However, I
>> wanted to raise awareness of this problem in case:
>> 1. there is strong opposition to this proposal
>> 2. others run into the same problem I did
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=91283
>> [2] https://github.com/systemd/systemd/commit/92d16a53e385781a55d9231d9
>> f8f89c1747ab0e4
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>>linux-bluetooth" in
>> the body of a message to [email protected]
>> 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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Statement of Confidentiality
The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any.
So it appears that our initial analysis was incorrect. In fact, all the dbus libraries behave the same. However, the Bluez GATT interface (and perhaps others) expects ObjectManager to behave incorrectly. Similarly, the Bluez test code contains a bug in its ObjectManager implementation. The offending line is here: http://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/example-gatt-server#n91
ObjectManager. GetManagedObjects() MUST NOT return itself in the set of returned children. The GATT interface needs to be updated to match this expectation.
----- Original Message -----
> The GATT service DBus interface currently requires that services
> implement the following interfaces:
> - org.freedesktop.DBus.ObjectManager
> - org.freedesktop.DBus.Properties
> - org.bluez.GattService1
>
> An unwritten expectation is that the ObjectManager's GetManagedObjects
> method should include the object itself in its return value. However,
> the spec for GetManagedObjects states otherwise.
>
> This currently works only because gdbus violates the spec.[1] Until
> today, systemd's sd-bus library was compliant with the spec and thus
> behaved differently from gdbus, making it impossible to use sd-bus with
> bluez.[2]
>
> I agree with Lennart's proposal that the best course of action is to
> fix the spec, not the implementations. This would mean that no change
> is needed for bluez (other than perhaps some documentation). However, I
> wanted to raise awareness of this problem in case:
> 1. there is strong opposition to this proposal
> 2. others run into the same problem I did
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=91283
> [2] https://github.com/systemd/systemd/commit/92d16a53e385781a55d9231d9
> f8f89c1747ab0e4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
DQoNCk9uIDgvMi8xNSwgMTo1NyBBTSwgIkx1aXogQXVndXN0byB2b24gRGVudHoiIDxsdWl6LmRl
bnR6QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5PbiBGcmksIEp1bCAzMSwgMjAxNSBh
dCAxMDo1MCBQTSwgQWRhbSBNb29yZQ0KPjxhZGFtLm1vb3JlQHNhdmFudHN5c3RlbXMuY29tPiB3
cm90ZToNCj4+DQo+Pg0KPj4gT24gNy8zMS8xNSwgMTI6NDUgUE0sICJPdGhtYW4sIE9zc2FtYSIg
PG9zc2FtYS5vdGhtYW5AaW50ZWwuY29tPiB3cm90ZToNCj4+DQo+Pj5IaSBBZGFtLA0KPj4+DQo+
Pj5PbiBGcmksIEp1bCAzMSwgMjAxNSBhdCAxMTowMCBBTSwgQWRhbSBNb29yZQ0KPj4+PGFkYW0u
bW9vcmVAc2F2YW50c3lzdGVtcy5jb20+IHdyb3RlOg0KPj4+PiBPc3NhbWEsIHRoYW5rcyBmb3Ig
c2hhcmluZyAtIEkgZGlkbqn2dCBoYXZlIHRoZSBoZWFydCB0byBnbyBkb3duIHRoYXQNCj4+Pj5w
YXRoDQo+Pj4+IDopICBOaWNlIHRvIGhhdmUgdGhhdCBzb2x1dGlvbiBhdmFpbGFibGUgdG9vLg0K
Pj4+DQo+Pj5IYSEgIEJlbGlldmUgeW91IG1lLCBJIHByZWZlcnJlZCBub3QgZ29pbmcgZG93biB0
aGlzIHBhdGggc2luY2UgaXQNCj4+PmJhc2ljYWxseSByZWludmVudHMgdGhlIHdoZWVsLiBidXQg
SSBkaWRuJ3QgaGF2ZSBtdWNoIGNob2ljZSBhdCB0aGUNCj4+PnRpbWUgc2luY2UgSSBuZWVkZWQg
dG8gZ2V0IHNvbWV0aGluZyBvdXQgdGhlIGRvb3IgdGhhdCBkaWRuJ3QgcmVseSB0b28NCj4+Pmhl
YXZpbHkgb24gdXBzdHJlYW0gcGF0Y2hlcyBiZWluZyBtZXJnZWQuDQo+Pj4NCj4+Pj4gSnVzdCBh
IHRob3VnaHQgLSBzaW5jZSB0aGUgQ2hhcmFjdGVyaXN0aWMgb2JqZWN0cyBtdXN0IHByb3ZpZGUg
dGhlaXINCj4+Pj4gc2VydmljZSBwYXRoIHZpYSBEQnVzIFByb3BlcnR5LCBmb3JjaW5nIHRoZWly
IHBhdGhzIHRvIGJlIGNoaWxkcmVuIG9mDQo+Pj4+dGhlDQo+Pj4+IHNlcnZpY2UgcGF0aCBtYXkg
YmUgcmVkdW5kYW50LCB1bmxlc3Mgc29tZSBsb2dpYyBpcyBwbGFubmVkIHRvIGJlDQo+Pj4+YmFz
ZWQNCj4+Pj5vbg0KPj4+PiB0aGUgc3RydWN0dXJlIG9mIHRoZSBPTSB0cmVlIGluIHRoZSBmdXR1
cmUuDQo+Pj4NCj4+PkFncmVlZC4gIEluIHRoaXMgY2FzZSwgSSBqdXN0IGZvbGxvd2VkIHRoZSBj
b252ZW50aW9uIGZvdW5kIGluIHRoZQ0KPj4+ZXhhbXBsZSBoaWVyYXJjaHkgZGVzY3JpYmVkIGlu
IHRoZSAiR0FUVCBNYW5hZ2VyIEhpZXJhcmNoeSIgc2VjdGlvbiBpbg0KPj4+dGhlIEJsdWVaIGRv
Yy9nYXR0LWFwaS50eHQgZG9jdW1lbnQsIGFzIHdlbGwgYXMgdGhlIGhpZXJhcmNoeSBmb3VuZCBp
bg0KPj4+dGhlIEJsdWVaIHRlc3QvZXhhbXBsZS1nYXR0LXNlcnZlciBQeXRob24gY29kZS4gIEdv
aW5nIHdpdGggdGhpcw0KPj4+aGllcmFyY2h5IGFsc28gbWltaWNzIHRoZSBHQVRUIHNlcnZpY2Ug
aGllcmFyY2h5IGRlc2NyaWJlZCBpbiB0aGUNCj4+PkJsdWV0b290aCBzcGVjLg0KPj4NCj4+IFll
YWgsIEkgdXNlZCB0aGUgc2FtZSBzdHJ1Y3R1cmUgaW4gbXkgaW1wbGVtZW50YXRpb24gLSB0aGF0
IHdhcyByZWFsbHkNCj4+IG1vcmUgb2YgYSBub3RlIGZvciB0aGUgbWFpbnRhaW5lcnMgdGhhdCBp
ZiB3ZSBjYW4gbGl2ZSB3aXRob3V0IGEgc3RyaWN0DQo+PiBzdHJ1Y3R1cmUsIGl0IG1pZ2h0IHNp
bXBsaWZ5IHRoZSBmaW5hbCBmaXguDQo+Pg0KPj4+DQo+Pj5UaGFua3MhDQo+Pj4tT3NzYW1hDQo+
DQo+SXQgc2VlbXMgdGhlIGlzc3VlIHdhcyBjbG9zZWQgY2F1c2VkIEdEQnVzIGFuZCBvdGhlciBi
aW5kaW5ncyBmb2xsb3cNCj50aGUgRC1CdXMgc3BlYyB0byB0aGUgd29yZCwgYnV0IGhvdyBvbmUg
d291bGQgbGlzdCBpbnRlcmZhY2VzIGluIHRoZQ0KPnJvb3QgJy8nPyBTbyBlaXRoZXIgJy8nIHNo
YWxsIGJlY29tZSBzcGVjaWFsIGFuZCBubyBvdGhlciBpbnRlcmZhY2UNCj5zaGFsbCBiZSByZWdp
c3RlcmVkIHRoZXJlIG9yIHRoZSBzcGVjIHNob3VsZCBiZSByZXdvcmRlZCB0byBpbmNsdWRlDQo+
dGhlIGluaXRpYWwgcGF0aCwgYnV0IHRoZSBmb3JtZXIgaXMgcHJvYmFibHkgbm90IGJhY2t3YXJk
IGNvbXBhdGlibGUNCj5zaW5jZSBhZmFpayBtb3N0IGJpbmRpbmdzIGFsbG93IGN1c3RvbSBpbnRl
cmZhY2VzIGluICcvJyBwYXRoLg0KDQpIaSBMdWl6LA0KDQpTaW5jZSB0aGVyZSBhcmUgYXQgbGVh
c3Qgc29tZSBiaW5kaW5ncyAobGlrZSBHbGliIEdEQnVzT2JqZWN0TWFuYWdlcikgdGhhdA0KZG8g
bm90IGFsbG93IGN1c3RvbSBpbnRlcmZhY2VzIGluIHRoZSBPYmplY3RNYW5hZ2VyIG9iamVjdCwg
d2UNCmNvdWxkIHRyeSB0byBhbGxvdyB0aGUgb2JqZWN0IGhvc3RpbmcgdGhlIE9iamVjdE1hbmFn
ZXIgaW50ZXJmYWNlIHRvDQphbHNvIGhvc3QgdGhlIEdhdHRTZXJ2aWNlIGludGVyZmFjZSwgYnV0
IG5vdCByZXF1aXJlIGl0Lg0KDQpGb3IgZXhhbXBsZSwgc29tZXRoaW5nIGxpa2UgdGhpcyBjb3Vs
ZCBhbHNvIGJlIGFjY2VwdGVkIGFzIHZhbGlkOg0KDQotPiAvY29tL2V4YW1wbGUNCnwNCi0+IC9j
b20vZXhhbXBsZS9oZWFydHJhdGUNCnwgfCAtIG9yZy5mcmVlZGVza3RvcC5EQnVzLk9iamVjdE1h
bmFnZXINCnwgfCAtIG9yZy5mcmVlZGVza3RvcC5EQnVzLlByb3BlcnRpZXMNCnwgfA0KfCAtPiAv
Y29tL2V4YW1wbGUvaGVhcnRyYXRlL3NlcnZpY2UNCnwgICB8IC0gb3JnLmZyZWVkZXNrdG9wLkRC
dXMuUHJvcGVydGllcw0KfCAgIHwgLSBvcmcuYmx1ZXouR2F0dFNlcnZpY2UxDQp8ICAgfA0KfCAg
IC0+IC9jb20vZXhhbXBsZS9oZWFydHJhdGUvc2VydmljZS9jaGFyMA0KfCAgICAgfCAtIG9yZy5m
cmVlZGVza3RvcC5EQnVzLlByb3BlcnRpZXMNCnwgICAgIHwgLSBvcmcuYmx1ZXouR2F0dENoYXJh
Y3RlcmlzdGljMQ0KfCAgICAgfA0KfCAgIC0+IC9jb20vZXhhbXBsZS9oZWFydHJhdGUvc2Vydmlj
ZS9jaGFyMQ0KfCAgICAgfCAtIG9yZy5mcmVlZGVza3RvcC5EQnVzLlByb3BlcnRpZXMNCnwgICAg
IHwgLSBvcmcuYmx1ZXouR2F0dENoYXJhY3RlcmlzdGljMQ0KfCAgICAgfA0KfCAgICAgLT4gL2Nv
bS9leGFtcGxlL2hlYXJ0cmF0ZS9zZXJ2aWNlL2NoYXIxL2Rlc2MwDQp8ICAgICAgIHwgLSBvcmcu
ZnJlZWRlc2t0b3AuREJ1cy5Qcm9wZXJ0aWVzDQp8ICAgICAgIHwgLSBvcmcuYmx1ZXouR2F0dERl
c2NyaXB0b3IxDQoNCklmIHdlIGNhbm5vdCBsaXZlIHdpdGggYWxsb3dpbmcgdGhlIHR3byBzdHJ1
Y3R1cmVzLCBpdCBtaWdodCBiZSBiZXR0ZXINCih0aG91Z2ggcGFpbmZ1bCkgdG8gYnJlYWsNCmJh
Y2t3YXJkIGNvbXBhdGliaWxpdHkgd2hpbGUgZXhwZXJpbWVudGFsIGZsYWcgaXMgc3RpbGwgZmx5
aW5nLCBhcw0KYmluZGluZ3MgdGhhdA0KZG8gYWxsb3cgY3VzdG9tIGludGVyZmFjZXMgY2FuIHN0
aWxsIGRvIHRoZSBhYm92ZSB3aXRoIGEgc21hbGwgY2hhbmdlLA0Kd2hlcmVhcyB0aGUgb3RoZXIg
YmluZGluZ3MNCmNhbm5vdCBpbXBsZW1lbnQgd2hhdCBpcyBjdXJyZW50bHkgZG9jdW1lbnRlZC4N
Cg0KUmVnYXJkaW5nIHlvdXIgc3BlYyByZXdvcmRpbmcgYWx0ZXJuYXRpdmUsIHdoaWNoIGluaXRp
YWwgcGF0aCBhcmUgeW91DQpyZWZlcnJpbmcgdG8/DQoNClRoYW5rcywNCi1BZGFtDQoNCg0KPg0K
Pg0KPi0tDQo+THVpeiBBdWd1c3RvIHZvbiBEZW50eg0KDQoNClN0YXRlbWVudCBvZiBDb25maWRl
bnRpYWxpdHkNCg0KVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBh
dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0
aGUgYWRkcmVzc2VlLiBUaGUgaW5mb3JtYXRpb24gbWF5IGFsc28gYmUgbGVnYWxseSBwcml2aWxl
Z2VkLiBUaGlzIHRyYW5zbWlzc2lvbiBpcyBzZW50IGluIHRydXN0LCBhbmQgdGhlIHNvbGUgcHVy
cG9zZSBvZiBkZWxpdmVyeSB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgYW55IHVzZSwgcmVwcm9kdWN0aW9u
IG9yIGRpc3NlbWluYXRpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGltbWVk
aWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBvciBhdCA1MDguNjgzLjI1
MDAgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55Lg0K
DQo=
Hi,
On Fri, Jul 31, 2015 at 10:50 PM, Adam Moore
<[email protected]> wrote:
>
>
> On 7/31/15, 12:45 PM, "Othman, Ossama" <[email protected]> wrote:
>
>>Hi Adam,
>>
>>On Fri, Jul 31, 2015 at 11:00 AM, Adam Moore
>><[email protected]> 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.
>
> Yeah, I used the same structure in my implementation - that was really
> more of a note for the maintainers that if we can live without a strict
> structure, it might simplify the final fix.
>
>>
>>Thanks!
>>-Ossama
It seems the issue was closed caused GDBus and other bindings follow
the D-Bus spec to the word, but how one would list interfaces in the
root '/'? So either '/' shall become special and no other interface
shall be registered there or the spec should be reworded to include
the initial path, but the former is probably not backward compatible
since afaik most bindings allow custom interfaces in '/' path.
--
Luiz Augusto von Dentz