- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 May 2016 21:22:06 +0000
- To: public-device-apis@w3.org
I'd prefer the latter. Since the sensor (type) defines its data
interface, I would use a separate property for that, like
```event.data.latitude``` or ```event.reading.latitude```.
In most cases a property bag would be enough, but it may even be a
fetching interface if needed, depending on the sensor, like
```event.data.nextChunk()```.
I've been experimenting with I/O APIs that support configuring the
read process with min / max bit length for a reading, and min / max
frequency of reading, which influences how data is exposed on the data
fetching interface. For this type of use I think Tim's suggestion to
expose a reader and use vanilla events would work better, with the
reservation that then Sensor should be an interface and not a base
class (in Java sense), so instead of subclassing, one could say
```javascript
interface MySensor { ... };
MySensor implements Sensor;
```
instead of
```javascript
interface MySensor: Sensor { ... };
```
However, with this design, and for this type of sensor use case I
would recommend exposing the data on the sensor as a separate object
property.
--
GitHub Notification of comment by zolkis
Please view or discuss this issue at
https://github.com/w3c/sensors/issues/103#issuecomment-220721614 using
your GitHub account
Received on Friday, 20 May 2016 21:22:07 UTC