Re: Proximity Events Feedback

Rick

We closed the issue  (LC-2740) related to your email in December on the Proximity Events specification.  I assume this is not a problem since as you noted in your message that you expected no change.

The WG has decided to keep the current design which reflects earlier decisions since it is not 'starting from scratch'.

The DeviceProximityEvent constructor takes an optional DeviceProxmityEventInit  dictionary that includes min, max and value.

The WG also has decided to keep the Ambient Light Events and Proximity Events specifications separate to allow independent conformance and testing, although they share commonality.

Please reply before 3 Sept if you have any concern or to acknowledge that the issue is closed.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group

LC-2740 https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-proximity-20121206/2740


Message received 2012-12-07 12:45:26:

> DATE: 2012-12-07 12:45:26
> FROM: ext Rick Waldron <waldron.rick@gmail.com>
> TO: Anne van Kesteren <annevk@annevk.nl>,public-device-apis <public-device-apis@w3.org>
> SUBJECT: Re: Proximity Events Feedback
> MAILBOX: mbox
> 
> 
> On Fri, Dec 7, 2012 at 5:39 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
>> 
>> If your device is not doing anything, e.g. completely stationary,
>> these sensors would theoretically not change and you would never be
>> able to get the actual state. That might be a mostly academic problem,
>> but this seems like another set of events that violate the spirit of
>> DOM Events. Kinda ambivalent on whether that's good or bad, but I
>> think it at least ought to be pointed out more clearly. And perhaps we
>> ought to define this more explicitly by having some kind of hook in
>> addEventListener?
>> 
> 
> 
> I've been thinking about this since the last call yesterday as well.
> 
> Early in my development of the Johnny-Five framework, I decided that all
> sensors must:
> 
> 1. Generate events
> 
>   - sensor.on("change", .... ); // Any change to the reading value(s)
>   - sensor.on("read", .... );     // Every sensor reading
> 
> 2. Allow value read accessors
> 
>   - sensor.value; // sensors w/ a single value
>   - sensor.axis.{ x, y, z } // multiple values (ie. accelerometer, as
>   shown here)
> 
> 3. Stream (in progress)
> 
>   - http://maxogden.com/node-streams.html
> 
> 
> But of course, this design is meant to facilitate an arbitrary number of
> sensors, eg. you might have an array of 4 proximity or sonar sensors on a
> robot to aid in navigation. This level of scalability may not
> seem practical for mobile devices, but then I'm reminded of
> navigator.getUserMedia that was originally spec'ed with no thought about
> multiple cameras—implementations then have to figure it out.
> 
> 
> I understand there is platform precedence to consider, ie. DeviceMotion and
> DeviceOrientation APIs and this nicely matches,  but If I was asked to
> start from scratch, I'd start with a Proximity (or
> DeviceProximity...something similar) constructor that initialized proximity
> objects that had properties: max, min and value and could dispatch events
> by inheriting EventTarget. I have no expectation that the current system
> would be changed like this, so consider this entirely "just for fun". :)
> 
> 
> Rick

Received on Wednesday, 21 August 2013 19:22:56 UTC