Hi Arman, >The problem is that ObjectManager has no clear way to tell a client that "this subset of object paths have been published" and when they are all available via GetManagedObjects. The most a client can do is observe the InterfacesAdded signal and that signal is sent on a per object path basis. For most external applications, >it might be enough but I would like application APIs to have to ability to say "all objects published, service is ready to use". Of course if DBus has these array object of characteristic property, there 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 more 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 acquire this subset of object in fact. I admit that applications have to handle these object information in their code to get this subset of object paths, but it make sense. If bluez export the array object of characteristic to application , why adapter did not export array object of devices and device not export array object of services ? >This is exactly the problem. A simple update of this property lets the user know that the hierarchy has been set up. For all I care, this could even be a simple boolean property such as "DiscoveryComplete" >but I kind of like the list of characteristics even though GetManagedObjects/InterfacesAdded, as you say, can achieve the same result. We have the similar "Includes" property already, so it's not entirely inconsistent from an API standpoint Some points I have referred to as above , there is another point I disagree with you. "Included " property is totally different with array object of characteristic, "Includes" property is essential that conform to least but enough information in DBus principle. Because if bluez does not export include property, application will not know if one service have included service or not, and which object services belong to it if includes exist. These information cannot be accessed without "Includes" property. >Are you referring to the HeartRateManager1 hierarchy? Since we're now building a generic API, we need a proper way of reference-counted, per-connection way to access the Client Characteristic Configuration descriptor. In this proposal, calling WriteValue on the CCC descriptor will always fail with WriteNotPermitted. >Do you have any suggestions for the method name or are you OK with StartNotify for now? We can always change it later. Yes , I refer to HeartRateManager1. The reason that I refer to this HeartRateManger1 is in my implemetaiton for existing gatt-api, I found LE profile will also affect the Gatt DBus Hierarchy. For example, when application use the RegisterWatcher method in Heartrate profile, heartrate characteristic whose CCC descriptor notification bit is on. Then heartrate characteristic in DBus and its' CCC descriptor have to emit propertychanged signal to application. When unregsiterWatcher ,CCC descriptor in DBus also has to emit propertychanged signal. Even if building this generic API, It stiil can not ignore this task. I am totally ok with generic notify API to application, but I am afraid that there would be conflict between LE profile and generic notify API. Because application does not know RegisterWatcher method has enable the notification. I do not know org.bluez.Inprogress error code could warn this condition or not. BTW, you saidi that calling WriteValue on the CCC descriptor will always fail with WriteNotPermitted. I think gatt_write_char function can write CCC descriptor , do you mean in WriteValue method to refuse write CCC descriptor on purpose and return WriteNotPermitted ? Thanks Chaojie Gu -----Original Message----- From: armansito@xxxxxxxxxx [mailto:armansito@xxxxxxxxxx] On Behalf Of Arman Uguray Sent: Wednesday, July 23, 2014 4:41 AM To: BlueZ development; Johan Hedberg; Gu, Chao Jie Subject: Re: [RFC v1 0/1] doc/gatt-api: New API properties and methods for the GATT D-Bus API. Hi Chaojie, Johan, Please see my responses inline: >> + array{object} Characteristics [read-only] >> + >> + Array of object paths representing the characteristics >> + of this service. This property is set only when the >> + characteristic discovery has been completed, however the >> + characteristic objects will become available via >> + ObjectManager as soon as they get discovered. > For this new property, I think there is not essential as other > property, because when characteristic discovery happen , all the > object path will setup on DBus Hierarchy. And user can get all the characteristic by ObjectManger. The problem is that ObjectManager has no clear way to tell a client that "this subset of object paths have been published" and when they are all available via GetManagedObjects. The most a client can do is observe the InterfacesAdded signal and that signal is sent on a per object path basis. For most external applications, it might be enough but I would like application APIs to have to ability to say "all objects published, service is ready to use". > Through this, User can use their own structure to get this array of object. > That is also why we need object property such as Device, Service and so on. > > And another reason , it have to wait for characteristic discovery > completed, it also can say that it have to wait for characteristic > setup DBus Hirarchy is ready. There exists asynchronous issues, if > user get this property operation before all the characteristic DBus setup is ready, it will make a mistake. > This is exactly the problem. A simple update of this property lets the user know that the hierarchy has been set up. For all I care, this could even be a simple boolean property such as "DiscoveryComplete" but I kind of like the list of characteristics even though GetManagedObjects/InterfacesAdded, as you say, can achieve the same result. We have the similar "Includes" property already, so it's not entirely inconsistent from an API standpoint. >> + void StartNotify() >> + >> + Starts a notification session from this characteristic >> + if it supports value notifications or indications. >> + >> + Possible Errors: org.bluez.Error.Failed >> + org.bluez.Error.InProgress >> + org.bluez.Error.NotSupported > About this method , I think other LE profile offer similar interface > to user, such as in heartrate profile. It will give registerwatcher > method, in which it will enable notify for heartrate. This will help > to trace descriptor including notification bit changed and send Propertychanged signal. Are you referring to the HeartRateManager1 hierarchy? Since we're now building a generic API, we need a proper way of reference-counted, per-connection way to access the Client Characteristic Configuration descriptor. In this proposal, calling WriteValue on the CCC descriptor will always fail with WriteNotPermitted. Do you have any suggestions for the method name or are you OK with StartNotify for now? We can always change it later. > "Insufficient Authorization" seems different from the other two in > that it's something that can't be attempted to be "fixed" from the > client side. It effectively means that our request was rejected by the > remote user, doesn't it? Good point, there is really not much bluetoothd or the external app can do in this case so we should probably propagate the authentication error separately from the NotPaired cases. Or do you think that it would be beneficial to have separate error definitions for Encryption and Authentication as well? Having Error.NotPaired and Error.Authentication seems reasonable to me. Cheers, Arman ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
