Re: Proximity Events Feedback

Hi Rick,

On 7.12.2012, at 19.45, ext Rick Waldron wrote:

> 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". :)

Your proposal has more to it than "just for fun" :)

We've mulled over various designs in this group, and have also though about using a somewhat similar design in one of the specs. There are definitely merits in such a design as you outline above, especially as it scales to arbitrary number of instances.

Thanks for sharing your thinking with us! We'll keep this in mind.

-Anssi

Received on Tuesday, 11 December 2012 11:51:19 UTC