Re: Proximity Events Feedback

I acknowledge the issue has been closed. Good luck.

Rick

On Wednesday, August 21, 2013, wrote:

> 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 <javascript:;>>
> > TO: Anne van Kesteren <annevk@annevk.nl <javascript:;>>,public-device-apis
> <public-device-apis@w3.org <javascript:;>>
> > SUBJECT: Re: Proximity Events Feedback
> > MAILBOX: mbox
> >
> >
> > On Fri, Dec 7, 2012 at 5:39 AM, Anne van Kesteren <annevk@annevk.nl<javascript:;>>
> 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
>
>
>
>
>
>
>
>