- From: Rick Waldron via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 May 2015 17:30:50 +0000
- To: public-device-apis@w3.org
> For instance, is there an assumption that the generic sensor API
isn't intended for continuous data, e.g. from a heart ECG monitor?
No, it's intended precisely for continuous data. The problem with this
example is that a generic sensor api that ships in a browser can't
possibly know about all heart ECG monitors, and furthermore can't
possibly know how to handle the data that comes from them.
The primary goal of the first version of the Sensor API is to cleanup
access to built-in sensors, eg.
- Accelerometer
- Ambient Light
- Battery
- Compass
- GPS/Geolocation
- Gyro
- Proximity
- Temperature
These are sensors that currently have disparate APIs, this is the
problem we are trying to solve. Simultaneously, we're designing
towards the future: @tobie and I want to make it such that
non-built-in sensors, eg. data via WebSocket (and other various
transport protocols), Stream, Serial, BLE, etc. can be "plugged in" to
`new Sensor({ ... })` (or whatever it's eventually called).
--
GitHub Notif of comment by rwaldron
See https://github.com/w3c/sensors/issues/18#issuecomment-103142809
Received on Monday, 18 May 2015 17:30:52 UTC