Hi Chen, On Thu, Oct 27, 2011 at 10:58 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > Characteristics have the ability to be notified or indicated, according to the profile requirements. We need to reflect those capabilities to the user, which can decide whether the characteristic will be notified or indicated. The bluetoothd will take care of the indication return code, and the watcher will be signaled with the existing mechanism. > > Would you rather see the register watcher get a second parameter to tell it the correct method, and change the properties to CanNotify, CanBroadcast to indicate the characteristic capability only (according to the char properties and availability of client char config descriptor)? If this is the case, than we may implicitly force notify or indicate only, not both of them, although the spec does not prohibit such behavior, and manage the watcher method internally. Yes, I think read-only property is better. This way, it will mostly be used to decide whether RegisterCharacteristicsWatcher() is supported or not. Also see the Luiz suggestion of using a list of strings. It allows easily extending these GATT properties on future. Regarding a new RegisterCharacteristicsWatcher() argument, I would avoid it if we can for now. We could implicitly have a priority inside BlueZ: * if characteristic supports indication, use indication (usually, this means the server needs to make sure the value was received, so it can e.g. free that value from its internal memory). * if characteristic supports notification, use notification * else, make RegisterCharacteristicsWatcher() returns a D-Bus error. That way, if a characteristic happens to support both indication and notification, it will always use indication. If in future we find that unsuitable for some profile, this can be changed, but let's try to not make things too complex now :) As a general suggestion, I propose you first get the API changes "approved" and committed upstream, then proceed with code changes. Unless you are comfortable with doing lots of rounds of patch submissions (or you are planning only RFC to get early comments). Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
