Hi Santiago, On Fri, Jun 24, 2011 at 6:06 AM, Santiago Carot <sancane@xxxxxxxxx> wrote: > Coming back to this issue. I was just wondering that we may not need > worried about this issue because the same case may occurs at GATT > level. I mean, an application using GATT could disturb the behaviour > of other one when it enables/disables characteristics. Actually, the current D-Bus "generic" GATT API does not enable/disable notifications (it assumes it has been enabled by some other mean, e.g. using gatttool). I had a patch to enable it when the first D-Bus client was interested on a characteristic (disabling was not possible yet), but it has not been submitted upstream (we are currently focusing on the core API for profiles AKA "attio driver"). So, as of now, some application using the generic D-Bus API will not affect the profile specific behavior, as it can only read/write characteristic values, and watch for already enabled notifications/indications. > Because of any application can enable/disable characteristics we don't > need to worry about to manage this in the Thermometer API. Remember > that in other threads in the mailing list people were speaking about > making a D-Bus API for GATT. Those applications using GATT could > enable notification for measures and disable it. On account of this, > it will be inevitable collisions in the use cases. I think we should adopt a refcount like behavior for notifications/indications, and bluez core should manage this. IOW, applications registered over d-bus grab a counter, on the first ref() the notification/indication is enabled on peer device, on last unref() it is disabled. My two cents, -- 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
