W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

RE: [sensors] Proximity Events

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Wed, 16 May 2012 12:57:34 +0000
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
CC: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <84BCA539DD96614691177EDA3CE4FF0546B177C3@ORSMSX101.amr.corp.intel.com>
> Ok, that makes sense to renamed it to "uninitialized".

Dzung Tran

-----Original Message-----
From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] 
Sent: Tuesday, May 15, 2012 11:38 PM
To: Tran, Dzung D
Cc: public-device-apis@w3.org public-device-apis@w3.org
Subject: Re: [sensors] Proximity Events


On 16.5.2012, at 8.28, ext Tran, Dzung D wrote:

> Also in this spec that user proximity should ever set to "unknown", why would this you get an event that set this to unknown unless the sensor is faulty? Then what happens? Will you keep getting "unknown". My opinion is that you will only toggle between near and far and vice versa. If the UA can't determine, then you will not get an event.

You have to define a default value for the attribute because some implementations may be unable to report the state when the parent object is created (the same reason as in the Battery Status API). And neither "near" nor "far" provided a sensible default value. I agree that "unknown" is not an optimal name, so I renamed it to "uninitialized" (e.g. the DataTransfer interface uses the same name, so there's some precedence for it on the Web platform).

The reason for going with a similar design for the "user proximity" as in the Battery Status API (and consequently different from the "device proximity") is that people came up with sensible use cases that required such a design. See e.g.:


Received on Wednesday, 16 May 2012 12:58:09 UTC

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