Hi Arman, > 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. You are right, we work on Tizen Bluetooth-frwk which is low-level service/application in system . Bluetooth-frwk can take a role to handle D-Bus informaiton 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 developer how to get characteristic array directly from bluetoothd. . Thanks Chaojie -----Original Message----- From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx] 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, 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. since InterfacesAdded is per object path, the extra Characteristics array makes sense. However that really only applies to application passively monitoring the bus objects and properties. The initiator of service discovery should only return from that method call when all other object signals have been send out. Similar to what we are doing with pairing or other potential long run asynchronous method calls. Regards Marcel -- 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
