- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Thu, 22 Aug 2013 13:40:20 -0400
- To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
- Message-ID: <CAHfnhfrcSXH56kT5BP9BsTKNeOv0ymNOHOy6_AC=wj1rdDvBbA@mail.gmail.com>
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 > > > > > > > >
Received on Thursday, 22 August 2013 17:40:51 UTC