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 23:14:18 -0300 Cc: Santiago Carot , linux-bluetooth@vger.kernel.org Message-Id: <092E3C75-499E-4E78-A167-F2DB57A0051E@signove.com> References: <1308661408-8364-1-git-send-email-sancane@gmail.com> <544C7016-5346-4C99-AEA9-C91AA84E3A42@signove.com> <75C285AD-9C2B-4F57-A998-D1346A68AEEE@signove.com> To: mike tsai Sender: linux-bluetooth-owner@vger.kernel.org List-ID: On Jun 24, 2011, at 11:27 AM, mike tsai wrote: > On Fri, Jun 24, 2011 at 6:20 AM, Elvis Pfutzenreuter wrote: >>>> (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. > could we apply an 'OR' logic to this inside the profile? Each > application will have its own property setting. > So if App-A enables both, then it will receive both immediate/.final > temperatures indication/notification. > if App-B enables only final, then it receives final temperature indication only. > There are still the issue of how profile can "wake up" application(s) > when notification/indication come. It is a tempting alternative, would render a very clean API. Thing is, you need to show each client app process a different 'view' of those D-Bus properties. It is feasible, but it is a new trick, not employed in other APIs.