Hi Chaojie, > 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. Explain to me how, using only the InterfacesAdded signal, an application can know that all characteristic objects under a service hierarchy have been added? The only way is if the external application already knows about service it's interacting with, which is not the case if you're building a generic application API on top of bluetoothd. Without what I'm proposing, you can't build a generic GATT application API without requiring cumbersome event handling for each service, characteristic, and descriptor object as they get added and have only partial access to these objects in the handlers as the objects are getting processed. This might be fine for low-level applications that interact with D-Bus directly, but for higher level app developers this is a real issue that we want to handle properly and make their lives easier. >why adapter did not export array object of devices and device not export array object of services ? Because it doesn't need to. You always deal with individual devices as they get added. You do NOT have this hierarchy with adapter where doing anything meaningful with the adapter requires you to have seen a certain set of multiple device objects. > 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. > You're right, as we move to the new shared GATT/ATT stack, we will have to change the way the LE plugins work. We need an internal API for bluetoothd that will handle discovery and other resource management (such as the CCC write) among daemon plugins and external applications. Without that, there will be conflict since the plugins, as they are today, perform these operations directly. Eventually what we want is to allow plugins to expose methods such as RegisterWatcher but have that call an internal API method so that UnregisterWatcher won't cause a write to the CCC descriptor if an external app called StartNotify on that characteristic and vice versa. So yes, there will be conflict unless we fix the whole stack, but that's what we'll do as we deprecate attrib/*. > 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 ? Yes, I meant the latter (WriteValue method will refuse on purpose). Cheers and thanks for the comments, Arman -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
