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

Re: [sensors] Proximity Events

From: Doug Turner <dougt@mozilla.com>
Date: Wed, 16 May 2012 10:32:13 -0700 (PDT)
To: Dzung D Tran <dzung.d.tran@intel.com>
Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, Anssi Kostiainen <anssi.kostiainen@nokia.com>
Message-ID: <1398080876.1040036.1337189533510.JavaMail.root@mozilla.com>
I understand the use case, but do not want to have an attribute.  There are multiple problems with having an attribute including - a sync API, staleness of the property, or requiring some "undefined" state.  More over, it complicates code.

Instead, I propose that we do something similar to what we did with device motion.  We will assume that user proximity will fire periodically so that callers do not need to check a property.

----- Original Message -----
From: "Dzung D Tran" <dzung.d.tran@intel.com>
To: "Anssi Kostiainen" <anssi.kostiainen@nokia.com>
Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Sent: Wednesday, May 16, 2012 5:57:34 AM
Subject: RE: [sensors] Proximity Events

> 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 17:32:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC