Return-Path: Subject: Re: [RFC] Health Thermometer Profile API Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Elvis Pfutzenreuter In-Reply-To: Date: Fri, 24 Jun 2011 10:20:51 -0300 Cc: linux-bluetooth@vger.kernel.org Message-Id: <75C285AD-9C2B-4F57-A998-D1346A68AEEE@signove.com> References: <1308661408-8364-1-git-send-email-sancane@gmail.com> <544C7016-5346-4C99-AEA9-C91AA84E3A42@signove.com> To: Santiago Carot Sender: linux-bluetooth-owner@vger.kernel.org List-ID: >> (cut) > > 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. Ok, but then the risk is clear. My feeling is that people are already "toning down" this API because of this. (One of the reasons my patch to add descriptor manipulation capability was rejected is that it was not meant to be a complete API and effort should go to profile-specific APIs. Without this, you can't toggle notifications and indications using generic GATT API anyway.) > > 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. > > For this reason I think that the Thermometer API should be the most > permissive possible. If any application disable intermediate or final > measures, the PropertyChanged signal will be triggered, well, there is > no problem, if there are agents interested in such measures they only > will have to enable the proterty in the API once again as usual. I can see two apps monitoring PropertyChanged to enforce opposite states of notification. It would create a lot of heat. > To summarize, I think we should add the properties to enable and > disable intermediate and final measures and to leave to applications > to take deccisions about how they are going to behave when this stuff > happen. I remember Marcel saying once that applications always do the wrong thing when given the chance :) In this respect, our opinions are pretty much opposite; IMHO one application must not have a way to create a problem to others. Notification interval is impossible to insulate, for there is just one per device, but we can do better for toggling of notifications. It would be nice to have more opinions on this.