Re: [sensors] Proximity Events

Hi Jonas, Doug, Dzung, All,

On 16.5.2012, at 21.56, ext Jonas Sicking wrote:

> 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.

Thanks for the excellent feedback! Now it looks like we should go with the second option. The use case that caused concerns is still valid, but it is not feasible to implement, it seems. I assume Doug is soon able to share his experiences based on running code, which should clear things up too.

Spec-wise, I interpret we should take the following concrete actions:

* Specify both the instances of proximity -- the "device proximity" and the "user proximity" -- similarly in the same draft. All the infrastructure is shared, so it makes sense (e.g. deviceorientation and devicemotion are spec'd together too). Only security and privacy considerations may differ. This would also make the lives of the editors a bit easier, which is a bonus :)

* The current "Device proximity" section would be copied over to the current "User proximity" section, the interfaces renamed s/Device/User/g. The event interface would only have a single attribute 'near' of type boolean.

All - let me know if you have concerns with this plan. Otherwise, we'll start updating the draft with Dzung as outlined above:

  http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

If there's no immediate agreement, we may wait for the next week's call before proceeding.

Thanks!

-Anssi

Received on Friday, 18 May 2012 12:08:14 UTC