Re: [sensors] Discrete vs continuous reporting modes

To me this seems not so much a sensor classification criterion than a 
reporting policy on the sensor side.

> do all platforms which make the distinction are consistent across 
sensors?

IMO it may not be consistent across all platforms for a given sensor, 
since it may depend on many things, including platform specific ones.

> are some sensors exposed both ways on the same platform?

It may well be exposed in both ways instance by instance, depending 
where are they installed for what purpose.

> how do we express that in JS? DiscreteSensor and ContinuousSensor 
that both inherit from Sensor?
> onchange (discrete) vs. ondata (continuous) events?

I think we should not explicitly classify sensors based on this, but 
have the policy on each sensor instead. A readonly property with a 
dictionary, and policy setters. For instance:
```javascript
enum SensorDataReportingPolicy {   // find a better name
    "periodic", "threshold", "in-range", "out-of-range"
};
```
```Sensor``` and ```SensorOptions``` already support "periodic" and 
"threshold", perhaps that's all you need for now. Then extend 
SensorOptions and Sensor to expose the policy:
```
partial dictionary SensorOptions {
    SensorDataReportingPolicy policy;
};

partial interface Sensor {
    Promise<void> setDataReportingPolicy(SensorDataReportingPolicy 
policy);
};
```
Of course, instead ```Promise<void>``` you could have ```void```, or 
just a settable attribute:
```
partial interface Sensor {
    attribute SensorDataReportingPolicy policy;
};
```

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

Received on Tuesday, 19 January 2016 07:47:34 UTC