Re: Bluetooth / NFC APIs

On 01/03/2010 14:41, Nilsson, Claes1 wrote:
> Hi Max,
>
> Yes, if we want to keep this simple it has, for each property, to be
> clarified which attribute the thresholds apply to.
>
> However, if we want it more flexible would it be possible add a way
> for the author to define which attribute the thresholds apply to? I
> am considering for example a proximity sensor that is only capable of
> detecting "near" and "far". In that case the value attribute is null
> and we can't define threshold values, i.e. not trigger when the
> device is "near" and "far" from for example the user's ear/face as.
> Would it complicate the "watch" method to much if we add the possible
> for the author to define which attribute the thresholds apply to?
> Your view?

Yes. In the case of Network for instance, the thresholds could apply to 
either upload or download bandwidth, and the specification fails to 
indicate which one it is. So, indeed, in some cases it would be nice if 
the attribute to which the thresholds apply were specified by the webapp 
author. Do you have a solution in mind?


> Furthermore, is it correct that if no threshold values are stated
> when the "watch" method is called, this means that a successCallback
> is invoked when any of the properties attributes changed its value?
> If this is correct interpreted this means that a device
> implementation of an API for an external sensor will have to be able
> to continuously report sensor values. Even though all implementation
> details (beare, protocols etc) are hidden buy this simple API for web
> developers, have you though if issues like battery drain etc?

That's an issue that was raised in the geolocation WG last November. The 
resolution was that the definition of "changed" is left to the 
implementation, which is thus at liberty to change its sampling rate to 
save battery and whatnot. The API doesn't see any of that. Adding 
sampling control to the API seems too complicated: you would have to 
support sampling over time (e.g. "every second"), or over value ("every 
time the ambient noise has changed by 10%", or "by 30dB"). That seems to 
low-level for the API.


> At last, a small comment on an editorial error. In the example in the
> beginning of section 4.8 I guess that maxThreshold should be
> highThreshold.

Thanks. There was also a "hiThreshold". All fixed.

Max.

Received on Monday, 1 March 2010 16:09:49 UTC