Re: [sensors] Dependency on [DOM] due to inheriting from EventTarget

> because they allow more use cases. For example, note how games use 
polling of mouse/keyboard and gamepad buttons to achieve lower 
latency. (I've gotten many complaints about the event-based mousemove 
API actually at conferences from game developers.) 

Thanks for bringing this up—it's **super** important. The current 
design of this spec understands the above and makes sure that it's 
well addressed. The `value` property of any sensor instance is an 
accessor that returns the most present possible reading of sensor. It 
starts off as `null` and once the underlying system has begun reading 
the actual sensor, it will return those reading values.

```js
let ambient = new sensors.Light({
  // some yet-undesigned way of telling this sensor to synchronize 
with requestAnimationFrame
});

requestAnimationFrame(function frame() {
  requestAnimationFrame(frame);

  // 
https://developer.mozilla.org/en-US/docs/Web/API/PowerManager/screenBrightness
  let brightness = calculateBrightness(ambient.value);  
  if (PowerManager.screenBrightness !== brightness) {
    PowerManager.screenBrightness = brightness;
  }
});
```



>  One nice thing about Observable is that you can declaratively start
 listening to one sensor when a message arrives from another:

> var values = sensor1.takeWhile(pos => pos.x - pos.y > 
0).concat(sensor2);

What exactly is the value of `values` and for how long?



> Combinators like concatenation are possible because Observables, 
like Iterables, have a concrete notion of completion.

Can you explain how this applies to a sensor that a program is 
expecting to read at a minimum frequency of 200Hz for the life of the 
program itself?


> Would you add the notion of completion to EventTarget? How would 
that be communicated? Would unsubscription be implied? 

I don't "endorse" it, but `removeEventListener` would be effective. 




-- 
GitHub Notif of comment by rwaldron
See https://github.com/w3c/sensors/issues/21#issuecomment-108052366

Received on Tuesday, 2 June 2015 18:50:02 UTC