RE: [RFC v1 0/1] doc/gatt-api: New API properties and methods for the GATT D-Bus API.

["Gu, Chao Jie" <chao.jie.gu@intel.com>]

Hi Arman,=20

> Explain to me how, using only the InterfacesAdded signal, an=20
> application can know that all characteristic objects under a service=20
> hierarchy have been added? The only way is if the external application=20
> already knows about service it's interacting with, which is not the=20
> case if you're building a generic application API on top of=20
> bluetoothd. Without what I'm proposing, you can't build a generic GATT=20
> application API without requiring cumbersome event handling for each=20
> service, characteristic, and descriptor object as they get added and=20
> have only partial access to these objects in the handlers as the=20
> objects are getting processed. This might be fine for low-level=20
> applications that interact with D-Bus directly, but for higher level=20
> app developers this is a real issue that we want to handle properly=20
> and make their lives easier.

You are right, we work on Tizen Bluetooth-frwk which is low-level service/a=
pplication in system . Bluetooth-frwk can take a role to handle D-Bus infor=
maiton and give defined API to application such as characteristic discovery=
 method, so we refer to different level application indeed.
>From your aspect, I understood that you consider that high level app develo=
per how to get characteristic array directly from bluetoothd. .=20

Thanks
Chaojie
-----Original Message-----
From: Marcel Holtmann [mailto:marcel@holtmann.org]=20
Sent: Thursday, July 24, 2014 12:33 AM
To: Arman Uguray
Cc: Gu, Chao Jie; BlueZ development; Johan Hedberg
Subject: Re: [RFC v1 0/1] doc/gatt-api: New API properties and methods for =
the GATT D-Bus API.

Hi Arman,

>> Of course if DBus has these array object of characteristic property, the=
re is more clear and easy for client to get. However, in my opinion, bluez =
just put out least but enough information in DBus Hierarchy for application=
 to use. Just you said, to add array object property , this could even be a=
 simple boolean property such as "DiscoveryComplete". That would be add mor=
e property in DBus, so on the contrary it would not let DBus Hierarchy look=
 simple and clear.
>> Through the objectAdded and InterfaceAdded Signal, application can acqui=
re this subset of object in fact.
>=20
> Explain to me how, using only the InterfacesAdded signal, an=20
> application can know that all characteristic objects under a service=20
> hierarchy have been added? The only way is if the external application=20
> already knows about service it's interacting with, which is not the=20
> case if you're building a generic application API on top of=20
> bluetoothd. Without what I'm proposing, you can't build a generic GATT=20
> application API without requiring cumbersome event handling for each=20
> service, characteristic, and descriptor object as they get added and=20
> have only partial access to these objects in the handlers as the=20
> objects are getting processed. This might be fine for low-level=20
> applications that interact with D-Bus directly, but for higher level=20
> app developers this is a real issue that we want to handle properly=20
> and make their lives easier.

since InterfacesAdded is per object path, the extra Characteristics array m=
akes sense. However that really only applies to application passively monit=
oring the bus objects and properties. The initiator of service discovery sh=
ould only return from that method call when all other object signals have b=
een send out. Similar to what we are doing with pairing or other potential =
long run asynchronous method calls.

Regards

Marcel