W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

RE: Sensors simplified (or not)

From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Thu, 11 Feb 2010 16:01:45 +0100
To: 'Max Froumentin' <maxfro@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA3232A1FB28C@seldmbx03.corpusers.net>
Hi Max,

I like this idea. It is more generic and provides possibilities for extensions. Assume we need some sensor discovery method?

Claes

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Max Froumentin
> Sent: onsdag den 10 februari 2010 17:13
> 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 Thursday, 11 February 2010 15:07:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC