RE: Bluetooth / NFC APIs

Hi again,

The straightforward solution would of course be to specify an additional attribute in the "options" interface that states which attribute in each property's interface the threshold attributes operate on. This would mean that we also have to define a list of enumerated constants for all attributes that the threshold attributes can operate on for all defined properties. 

This is not very flexible and extensions according to section 5 is a problem. However, you have already indicated enumerated constants as an issue with extensions.

Any better idea?

Claes

> -----Original Message-----
> From: Max Froumentin [mailto:maxfro@opera.com]
> Sent: måndag den 1 mars 2010 17:09
> To: Nilsson, Claes1
> Cc: Nikolai Onken; public-device-apis@w3.org
> Subject: 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 Tuesday, 2 March 2010 15:36:21 UTC