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?
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.
Hi,
On Mon, Nov 30, 2015 at 9:59 AM, Johan Hedberg <[email protected]> wrote:
> Hi,
>
> On Mon, Nov 30, 2015, Jonas Holmberg wrote:
>> 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.
>
> It appears to be a bug in the BlueZ implementation and D-Bus API. It
> was already discussed many months ago, but no one seems to have
> submitted patches to fix it:
>
> http://comments.gmane.org/gmane.linux.bluez.kernel/63291
> https://bugs.freedesktop.org/show_bug.cgi?id=91283
> https://github.com/systemd/systemd/issues/525#issuecomment-126746787
Yep, I guess we lost track of it in the mailing list but we should
definitely fix it. One idea that comes to me is to change the
RegisterService to RegisterApplication and then have all its services
registered at once:
diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
index d832c73..f1940ba 100644
--- a/doc/gatt-api.txt
+++ b/doc/gatt-api.txt
@@ -270,9 +270,9 @@ must be available on the root service path. An
example application hierarchy
containing two separate GATT services may look like this:
-> /com/example
+ | - org.freedesktop.DBus.ObjectManager
|
-> /com/example/service0
- | | - org.freedesktop.DBus.ObjectManager
| | - org.freedesktop.DBus.Properties
| | - org.bluez.GattService1
| |
@@ -289,7 +289,6 @@ containing two separate GATT services may look like this:
| - org.bluez.GattDescriptor1
|
-> /com/example/service1
- | - org.freedesktop.DBus.ObjectManager
| - org.freedesktop.DBus.Properties
| - org.bluez.GattService1
|
@@ -309,21 +308,21 @@ Service org.bluez
Interface org.bluez.GattManager1 [Experimental]
Object path [variable prefix]/{hci0,hci1,...}
-Methods void RegisterService(object service, dict options)
+Methods void RegisterApplication(object application,
dict options)
- Registers a local GATT service hierarchy as described
+ Registers a local GATT services hierarchy as described
above.
- "service" object path together with the D-Bus system
- bus connection ID define the identification of the
- application registering a GATT based service.
+ The application object path together with the D-Bus
+ system bus connection ID define the identification of
+ the application registering a GATT based service.
Possible errors: org.bluez.Error.InvalidArguments
org.bluez.Error.AlreadyExists
- void UnregisterService(object service)
+ void UnregisterApplication(object application)
- This unregisters the service that has been
+ This unregisters the services that has been
previously registered. The object path parameter
must match the same value that has been used
on registration.
--
Luiz Augusto von Dentz
Hi,
On Mon, Nov 30, 2015, Jonas Holmberg wrote:
> 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.
It appears to be a bug in the BlueZ implementation and D-Bus API. It
was already discussed many months ago, but no one seems to have
submitted patches to fix it:
http://comments.gmane.org/gmane.linux.bluez.kernel/63291
https://bugs.freedesktop.org/show_bug.cgi?id=91283
https://github.com/systemd/systemd/issues/525#issuecomment-126746787
Johan
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 [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
>
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.
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi
On 01/11/2016 12:22 AM, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Mon, Nov 30, 2015 at 6:12 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi,
>>
>> On Mon, Nov 30, 2015 at 9:59 AM, Johan Hedberg <[email protected]> wrote:
>>> Hi,
>>>
>>> On Mon, Nov 30, 2015, Jonas Holmberg wrote:
>>>> 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.
>>> It appears to be a bug in the BlueZ implementation and D-Bus API. It
>>> was already discussed many months ago, but no one seems to have
>>> submitted patches to fix it:
>>>
>>> http://comments.gmane.org/gmane.linux.bluez.kernel/63291
>>> https://bugs.freedesktop.org/show_bug.cgi?id=91283
>>> https://github.com/systemd/systemd/issues/525#issuecomment-126746787
>> Yep, I guess we lost track of it in the mailing list but we should
>> definitely fix it. One idea that comes to me is to change the
>> RegisterService to RegisterApplication and then have all its services
>> registered at once:
>>
>> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
>> index d832c73..f1940ba 100644
>> --- a/doc/gatt-api.txt
>> +++ b/doc/gatt-api.txt
>> @@ -270,9 +270,9 @@ must be available on the root service path. An
>> example application hierarchy
>> containing two separate GATT services may look like this:
>>
>> -> /com/example
>> + | - org.freedesktop.DBus.ObjectManager
>> |
>> -> /com/example/service0
>> - | | - org.freedesktop.DBus.ObjectManager
>> | | - org.freedesktop.DBus.Properties
>> | | - org.bluez.GattService1
>> | |
>> @@ -289,7 +289,6 @@ containing two separate GATT services may look like this:
>> | - org.bluez.GattDescriptor1
>> |
>> -> /com/example/service1
>> - | - org.freedesktop.DBus.ObjectManager
>> | - org.freedesktop.DBus.Properties
>> | - org.bluez.GattService1
>> |
>> @@ -309,21 +308,21 @@ Service org.bluez
>> Interface org.bluez.GattManager1 [Experimental]
>> Object path [variable prefix]/{hci0,hci1,...}
>>
>> -Methods void RegisterService(object service, dict options)
>> +Methods void RegisterApplication(object application,
>> dict options)
>>
>> - Registers a local GATT service hierarchy as described
>> + Registers a local GATT services hierarchy as described
>> above.
>>
>> - "service" object path together with the D-Bus system
>> - bus connection ID define the identification of the
>> - application registering a GATT based service.
>> + The application object path together with the D-Bus
>> + system bus connection ID define the identification of
>> + the application registering a GATT based service.
>>
>> Possible errors: org.bluez.Error.InvalidArguments
>> org.bluez.Error.AlreadyExists
>>
>> - void UnregisterService(object service)
>> + void UnregisterApplication(object application)
>>
>> - This unregisters the service that has been
>> + This unregisters the services that has been
>> previously registered. The object path parameter
>> must match the same value that has been used
>> on registration.
> Any comments to the patches Ive sent upstream, Id like to push them
> which will result in breaking the current (experimental) API so I hope
> it doesn't take anyone by surprise.
>
I've tested the patches and they work good for me, I can now register GATT services (and they work well) one level down the D-Bus Object Manager, Glib doesn't assert anymore.
Hi,
On 01/10/2016 11:22 PM, Luiz Augusto von Dentz wrote:
> Hi,
>
> On Mon, Nov 30, 2015 at 6:12 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi,
>>
>> On Mon, Nov 30, 2015 at 9:59 AM, Johan Hedberg <[email protected]> wrote:
>>> Hi,
>>>
>>> On Mon, Nov 30, 2015, Jonas Holmberg wrote:
>>>> 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.
>>>
>>> It appears to be a bug in the BlueZ implementation and D-Bus API. It
>>> was already discussed many months ago, but no one seems to have
>>> submitted patches to fix it:
>>>
>>> http://comments.gmane.org/gmane.linux.bluez.kernel/63291
>>> https://bugs.freedesktop.org/show_bug.cgi?id=91283
>>> https://github.com/systemd/systemd/issues/525#issuecomment-126746787
>>
>> Yep, I guess we lost track of it in the mailing list but we should
>> definitely fix it. One idea that comes to me is to change the
>> RegisterService to RegisterApplication and then have all its services
>> registered at once:
>>
>> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
>> index d832c73..f1940ba 100644
>> --- a/doc/gatt-api.txt
>> +++ b/doc/gatt-api.txt
>> @@ -270,9 +270,9 @@ must be available on the root service path. An
>> example application hierarchy
>> containing two separate GATT services may look like this:
>>
>> -> /com/example
>> + | - org.freedesktop.DBus.ObjectManager
>> |
>> -> /com/example/service0
>> - | | - org.freedesktop.DBus.ObjectManager
>> | | - org.freedesktop.DBus.Properties
>> | | - org.bluez.GattService1
>> | |
>> @@ -289,7 +289,6 @@ containing two separate GATT services may look like this:
>> | - org.bluez.GattDescriptor1
>> |
>> -> /com/example/service1
>> - | - org.freedesktop.DBus.ObjectManager
>> | - org.freedesktop.DBus.Properties
>> | - org.bluez.GattService1
>> |
>> @@ -309,21 +308,21 @@ Service org.bluez
>> Interface org.bluez.GattManager1 [Experimental]
>> Object path [variable prefix]/{hci0,hci1,...}
>>
>> -Methods void RegisterService(object service, dict options)
>> +Methods void RegisterApplication(object application,
>> dict options)
>>
>> - Registers a local GATT service hierarchy as described
>> + Registers a local GATT services hierarchy as described
>> above.
>>
>> - "service" object path together with the D-Bus system
>> - bus connection ID define the identification of the
>> - application registering a GATT based service.
>> + The application object path together with the D-Bus
>> + system bus connection ID define the identification of
>> + the application registering a GATT based service.
>>
>> Possible errors: org.bluez.Error.InvalidArguments
>> org.bluez.Error.AlreadyExists
>>
>> - void UnregisterService(object service)
>> + void UnregisterApplication(object application)
>>
>> - This unregisters the service that has been
>> + This unregisters the services that has been
>> previously registered. The object path parameter
>> must match the same value that has been used
>> on registration.
>
> Any comments to the patches Ive sent upstream, Id like to push them
> which will result in breaking the current (experimental) API so I hope
> it doesn't take anyone by surprise.
>
It looks fine to me fwiw.
/J
Hi,
On Mon, Nov 30, 2015 at 6:12 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> On Mon, Nov 30, 2015 at 9:59 AM, Johan Hedberg <[email protected]> wrote:
>> Hi,
>>
>> On Mon, Nov 30, 2015, Jonas Holmberg wrote:
>>> 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.
>>
>> It appears to be a bug in the BlueZ implementation and D-Bus API. It
>> was already discussed many months ago, but no one seems to have
>> submitted patches to fix it:
>>
>> http://comments.gmane.org/gmane.linux.bluez.kernel/63291
>> https://bugs.freedesktop.org/show_bug.cgi?id=91283
>> https://github.com/systemd/systemd/issues/525#issuecomment-126746787
>
> Yep, I guess we lost track of it in the mailing list but we should
> definitely fix it. One idea that comes to me is to change the
> RegisterService to RegisterApplication and then have all its services
> registered at once:
>
> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
> index d832c73..f1940ba 100644
> --- a/doc/gatt-api.txt
> +++ b/doc/gatt-api.txt
> @@ -270,9 +270,9 @@ must be available on the root service path. An
> example application hierarchy
> containing two separate GATT services may look like this:
>
> -> /com/example
> + | - org.freedesktop.DBus.ObjectManager
> |
> -> /com/example/service0
> - | | - org.freedesktop.DBus.ObjectManager
> | | - org.freedesktop.DBus.Properties
> | | - org.bluez.GattService1
> | |
> @@ -289,7 +289,6 @@ containing two separate GATT services may look like this:
> | - org.bluez.GattDescriptor1
> |
> -> /com/example/service1
> - | - org.freedesktop.DBus.ObjectManager
> | - org.freedesktop.DBus.Properties
> | - org.bluez.GattService1
> |
> @@ -309,21 +308,21 @@ Service org.bluez
> Interface org.bluez.GattManager1 [Experimental]
> Object path [variable prefix]/{hci0,hci1,...}
>
> -Methods void RegisterService(object service, dict options)
> +Methods void RegisterApplication(object application,
> dict options)
>
> - Registers a local GATT service hierarchy as described
> + Registers a local GATT services hierarchy as described
> above.
>
> - "service" object path together with the D-Bus system
> - bus connection ID define the identification of the
> - application registering a GATT based service.
> + The application object path together with the D-Bus
> + system bus connection ID define the identification of
> + the application registering a GATT based service.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.AlreadyExists
>
> - void UnregisterService(object service)
> + void UnregisterApplication(object application)
>
> - This unregisters the service that has been
> + This unregisters the services that has been
> previously registered. The object path parameter
> must match the same value that has been used
> on registration.
Any comments to the patches Ive sent upstream, Id like to push them
which will result in breaking the current (experimental) API so I hope
it doesn't take anyone by surprise.
--
Luiz Augusto von Dentz