W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2016

Re: [sensors] Should SensorReadingEvent carry reading payload?

From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
Date: Fri, 20 May 2016 21:22:06 +0000
To: public-device-apis@w3.org
Message-ID: <issue_comment.created-220721614-1463779325-sysbot+gh@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

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