- From: Tran, Dzung D <dzung.d.tran@intel.com>
- Date: Wed, 10 Feb 2010 14:58:02 -0800
- To: Max Froumentin <maxfro@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
I think this is simple and should work fairly well. Just a couple of questions/comments: So for Ambient Light Sensor, the value of 1.0 means direct sunlight and 0.0 means complete darkness. Is this your understanding? How would a programmer interpret these values when both existed such as 1.0 for normalized value and value = 79.9, max = 90.0, min = 0.0. Thanks Dzung Tran -----Original Message----- From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Max Froumentin Sent: Wednesday, February 10, 2010 08:13 AM To: public-device-apis@w3.org Subject: Sensors simplified (or not) Looking at the similarity of all the Sensor APIs (Ambient Noise, Temperature, etc.), and thinking about extensibility I thought I'd merge all the interfaces into 1. Something like: [NoInterfaceObject] interface SensorReading { readonly attribute float? value; readonly attribute float? min; readonly attribute float? max; readonly attribute float? normalizedValue; }; (don't mind the names for now.) The value is meant to be a physical value with a unit (set by each sensor's specification). min and max should also be in that unit. But there are many sensors for which the native API doesn't report a physical value. For instance, the brightness is sometimes reported as a % value (OS X, IIRC). In other cases, the proximity sensor reports 2 values: near and far (Android). That's why I added normalizedValue, which is meant to be a unit-less value from 0.0 to 1.0 - Is that a good model? - Is there a better alternative? - If not, are there better names than "SensorReading" and "normalizedValue"? Max.
Received on Wednesday, 10 February 2010 23:06:13 UTC