Re: [RFC] Health Thermometer Profile API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux