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

Re: [sensors] Device Proximity (was: Device light and proximity sensor)

From: Doug Turner <dougt@mozilla.com>
Date: Wed, 9 May 2012 07:43:38 -0700
Cc: Anssi Kostiainen <anssi.kostiainen@nokia.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <0E84DD84-B643-4BA1-81C6-679F9485E133@mozilla.com>
To: "Tran, Dzung D" <dzung.d.tran@intel.com>
My initial feedback:

1) great! Thanks for putting this together.

2) Under 4. Security and Privacy Considerations

I disagree with the wording here.  This wording is too strong.  Some of the sensors (like light and proximity) may not need any UI or expressed consent.  Others (like device noise) may need more consideration.  I think we should rework this to say SHOULD or MAY.


3) Under 5.1 (and 5.1.1)

The callback may be incorrect.  Basically, you'll have functions that looks like:

function (event) {
  event.value
  event.max  (optionally)
  event.min   (optionally)
}


4) Acknowledgements

You may want to also include the work on proximity sensors here:  http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/




On May 9, 2012, at 6:37 AM, Tran, Dzung D wrote:

> I checked in the Sensor spec last night at:
> 
> http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html
> 
> Thanks
> Tran
> 
> -----Original Message-----
> From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] 
> Sent: Wednesday, May 09, 2012 5:15 AM
> To: public-device-apis@w3.org public-device-apis@w3.org
> Subject: [sensors] Device Proximity (was: Device light and proximity sensor)
> 
> Hi All,
> 
> On 7.5.2012, at 18.31, ext Robin Berjon wrote:
> 
>> Doug put together the two proposals below. Since they happen to be both on our plate and delightfully simple I was wondering if there was interest in this group in taking them further?
> 
> I took Doug's Device Proximity implementation [1] and started spec'ing it at [2].
> 
> Why pick only one sensor cf. all-in-one spec?
> 
> First, historically working on small self-contained features separately has worked fairly nicely in this working group.
> 
> Second, once we'll get the design right for one sensor (and getting it right is easier with one sensor on our plate at a time), it should be relatively easy to apply a similar design to the rest of the sensors that are of interest.
> 
> Third, I think security and privacy considerations should be taken seriously for all the sensors. And they vary sensor by sensor. By working on each sensor separately each one of them is more likely to get properly scrutinized. I believe we can merge the work later on if that is seen beneficial.
> 
> That said, this draft [2] is an initial version that is likely to contain rough edges and leaves many parts unspecified, notably, the issue around side effects remains. I'd be especially happy if someone comes up with constructive feedback early on on how to solve the side effects issue (or has the ship has already sailed with the Device Orientation in the wild?). We touched the issue previously as part of the Battery Status spec, and Anne sent great feedback back then that I encourage everyone interested in this work to revisit (search the archives; eventually we settled on an alternative design for the Battery Status API that completely sidestepped the side effects issue, so we never came to a conclusion on that one).
> 
> Finally, I'm happy if someone would like to step in and share the workload by co-editing the spec.
> 
> -Anssi
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=738131
> [2] http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html
> 
> 
> 
Received on Wednesday, 9 May 2012 14:44:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 14:44:13 GMT