- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 16 May 2012 11:56:49 -0700
- To: Doug Turner <dougt@mozilla.com>
- Cc: Dzung D Tran <dzung.d.tran@intel.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>, Anssi Kostiainen <anssi.kostiainen@nokia.com>
On Wed, May 16, 2012 at 10:32 AM, Doug Turner <dougt@mozilla.com> wrote: > 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. Like Doug, I'm not a fan of the current solution. The problem is that as the spec is written currently, there is an expectation that a page can always get the navigator.proximitystate property to see if the user is near/far. This leaves the implementation with a couple of bad options: 1. Always keep the proximity sensor on as long as the browser is running. Do this even if the page never actually accesses the navigator.proximitystate property, just in case it will do so later. 2. When navigator.proximitystate is accessed, block the browser thread until the sensor has been turned on and delivered data. Neither of these solutions seem acceptable to me. We should either: * Add a on/off switch which allows the page to control if the property is being kept up to date. The switch would default to the "off" state. * Go with the same solution as the deviceproximity event. I tend to think that the second solution is more consistent with other sensor solutions. / Jonas
Received on Wednesday, 16 May 2012 18:57:48 UTC