On Jun 24, 2011, at 11:27 AM, mike tsai wrote: > On Fri, Jun 24, 2011 at 6:20 AM, Elvis Pfutzenreuter <epx@xxxxxxxxxxx> 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.-- 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
