W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2015

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

From: Rick Waldron via GitHub <sysbot+gh@w3.org>
Date: Tue, 02 Jun 2015 20:07:56 +0000
To: public-device-apis@w3.org
Message-ID: <issue_comment.created-108081529-1433275673-sysbot+gh@w3.org>
> If all you are doing is listening to a single sensor for the life of
 a program and taking no action beyond updating a variable, 
composition won't be very interesting to you. 

This is most real world use cases. These things are long running and 
serve only to update and inform some other operation: 

- Checking Proximity of face to device to automatically (so you don't 
cheek press)
- Any environmental monitor that affects change via output to any kind
 of effectors (eg. smooth display updates based on any number of 
sensory inputs, eg. updating the screen brightness by monitoring 
ambient light)
- Controlling the position of a drone by updating its PID controllers 
with data from a smart phone's gyro and accelerometer, which are being
 used as a virtual "joystick" in a remote control app (see: FreeFlight
 3, or anyone that works on a modern farm)
- Monitoring moisture in the surrounding environment (don't drop your 
phone in the toilet)
- Controlling the volume of headphones based on ambient sound level 
(good for ignoring everyone on crowded noisy subways)
- Monitoring heart rate via a built-in smartwatch sensor
- Ambient temperature monitoring, coupled with an algorithm that uses 
Compass, Acceleration, GPS and GSM location data, which sends a 
message to central "smart home" system to adjust where you are to who 
you are, and readjust/balance to any other user of the same system. 
- GPS/Compass/GSM data to track person or vehicle while using 
turn-by-turn directions
- GPS/Compass/GSM data is also used to make "traffic" display more 
accurate
- ^^ + Accelerometer/Gyroscope for monitoring a bike ride, walk, jog, 
etc. 
- All of the above for any kind of game. 


Here's an example that the `sensor.takeWhile` form might be useful 
for: 

- Fingerprint validation. 

(but can still be done without it)


> My suspicion is that there are many use cases for combining sensors 
into new more complex sensor streams.

Yes, PID controllers, fusion algorithms, etc. but the API doesn't have
 to more than `object.value` for those to be easy and awesome to 
write. 


> sensor1.takeWhile(pos => pos.x - pos.y)
> This creates an observable which ends when the condition is met.

What is the condition? Truthy-ness/falsey-ness of the return value?


> Without an explicit completion semantic in EventTarget, building 
either of these methods isn't possible. We'd have to add more 
semantics to EventTarget to make that happen.

Or not at all because it's not immediately obvious (or even remotely 
evident) that this is a desirable semantic trait that befits a 
solution for the most common use cases. 


-- 
GitHub Notif of comment by rwaldron
See https://github.com/w3c/sensors/issues/21#issuecomment-108081529
Received on Tuesday, 2 June 2015 20:07:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC