Re: [sensors] Discrete vs continuous reporting modes

> if a given sensor is implemented as a discrete sensor on a given 
platform, it is going to be impossible to turn it into a reliable 
continuous sensor on that platform

I see... the main question is still how to expose it. So when you 
create a sensor, you already know how it is implemented, and there are
 constraints on what reporting policies can be set. In simplest 
approach setting a policy (e.g. "continuous") would fail for some of 
the sensors. The implementation needs to know what are the allowed 
values, so the list of allowed policies should be provided during 
construction. 
```javascript
partial dictionary SensorOptions {
    sequence<SensorDataReportingPolicy> policies;  // allowed policies
    SensorDataReportingPolicy policy;  // the selected policy
};
```
So in subclassing vs parametrizing I would be still in favor of the 
latter: instead of creating an instance of a DiscreteSensor, we could 
create a generic Sensor with more limited data reporting capabilities 
(given to the constructor). This is simpler both to implement and use.

The problem I see with the classification approach is that it's too 
much tied to a current policy of hardcoding behavior; it may also 
create confusion that some sensors are sometimes DiscreteSensors but 
in other deployments they could be ContinuousSensor. Nit: the names 
are not intuitive to people who don't know this particular problem. 
One may think discrete refers to digital, and continuous to analog.

Also, differentiation between ```onchange``` and ```ondata``` 
shouldn't be misused for handling this issue. AFAIK usually 
```onchange``` is used when a property of the object has changed, and 
```ondata``` would be the proper event for handling data. The spec is 
not clear about this, and the examples see to use ```onchange``` where
 ```ondata``` would seem more appropriate.


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

Received on Tuesday, 19 January 2016 10:56:54 UTC