Re: [sensors] Should SensorReadingEvent carry reading payload?

This is quite an evergreen topic and pops up with data APIs every now 
and then.
For my taste a vanilla event and data fetcher is better for large data
 sets, and a specialized event is simpler and better for the generic 
sensor use case (small amount of data coming at high possible rate):
- with events clients can track better the data changes, without the 
need to use time stamps. 
- subclasses of Sensor will likely have their own data models, which 
should be encapsulated at their level, and not exposed through a 
getter at the base.

So what I would do (which is not necessarily what this spec should do,
 but consider it):
- remove the ```reading``` property from ```Sensor```
- provide the data in the ```SensorReadingEvent```s of each subclass 
of Sensor
- remove time stamp (at least for now), that will also tame issue #101
- let subclasses encapsulate their data model
- optionally (but desirable) rename ```onchange``` to ```ondata``` or 
```ondatachange``` to denote that it was specifically the data 
representation of the sensor that has changed, and not some other 
properties.

-- 
GitHub Notification of comment by zolkis
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/103#issuecomment-220582506 using
 your GitHub account

Received on Friday, 20 May 2016 11:31:23 UTC