Re: [RFC] Health Thermometer Profile API

On Jun 24, 2011, at 11:27 AM, mike tsai wrote:

On Fri, Jun 24, 2011 at 6:20 AM, Elvis Pfutzenreuter [off-list ref] wrote:

quoted

quoted

quoted

(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.)

quoted

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.

quoted

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.