On 8/2/15, 1:57 AM, "Luiz Augusto von Dentz" <luiz.dentz@xxxxxxxxx> wrote:
>Hi,
>
>On Fri, Jul 31, 2015 at 10:50 PM, Adam Moore
><adam.moore@xxxxxxxxxxxxxxxxx> wrote:
>>
>>
>> On 7/31/15, 12:45 PM, "Othman, Ossama" <ossama.othman@xxxxxxxxx> wrote:
>>
>>>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.
>>
>> 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.
Hi Luiz,
Since there are at least some bindings (like Glib GDBusObjectManager) that
do not allow custom interfaces in the ObjectManager object, we
could try to allow the object hosting the ObjectManager interface to
also host the GattService interface, but not require it.
For example, something like this could also be accepted as valid:
-> /com/example
|
-> /com/example/heartrate
| | - org.freedesktop.DBus.ObjectManager
| | - org.freedesktop.DBus.Properties
| |
| -> /com/example/heartrate/service
| | - org.freedesktop.DBus.Properties
| | - org.bluez.GattService1
| |
| -> /com/example/heartrate/service/char0
| | - org.freedesktop.DBus.Properties
| | - org.bluez.GattCharacteristic1
| |
| -> /com/example/heartrate/service/char1
| | - org.freedesktop.DBus.Properties
| | - org.bluez.GattCharacteristic1
| |
| -> /com/example/heartrate/service/char1/desc0
| | - org.freedesktop.DBus.Properties
| | - org.bluez.GattDescriptor1
If we cannot live with allowing the two structures, it might be better
(though painful) to break
backward compatibility while experimental flag is still flying, as
bindings that
do allow custom interfaces can still do the above with a small change,
whereas the other bindings
cannot implement what is currently documented.
Regarding your spec rewording alternative, which initial path are you
referring to?
Thanks,
-Adam
>
>
>--
>Luiz Augusto von Dentz
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.
ÿ淸º{.nÇ+돴윯돪†+%듚ÿ깁負¥Šwÿº{.nÇ+돴¥Š{깰¹nzÚ(¶ â왲^n‡r⊆¦zË곷h솳鈺Ú&｛àz요z받쀺+€Ê+zf＂·hš닱~넮녬iÿÿï곴ÿ묎çz_溫æj:+v돣þ)山øm
