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

--------------------------------------------------
From: "Tran, Dzung D" <dzung.d.tran@intel.com>
Sent: Wednesday, May 09, 2012 7:07 PM
To: "Anssi Kostiainen" <anssi.kostiainen@nokia.com>; 
<public-device-apis@w3.org>
Subject: RE: [sensors] Device Proximity (was: Device light and proximity 
sensor)

> I checked in the Sensor spec last night at:
>
> http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html

I would like to comment on an aspect that is common to both specs. The 
sensors vary from device-to-device. Also, It is left to the implementation 
to decide at what granularity the event is fired. Therefore, we should have 
following parameters in the event Callback:
1. Granularity - Granularity with which underlying sensor can report data
2. Interval - interval at which the sensors are polled to collect data

- Balaji N V
Samsung



>
> 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:47:18 UTC