Tobie Langel

@richtr agreed. That's my main concern re feature detection. This is more about enumerating multiple sensors of the same type. The approach taken by `getUserMedia` (which you suggested in https://github.com/w3c/sensors/issues/8#issuecomment-63328405),...

Tying this in to #9. I think it's critical here to have a better understanding of how sensors are discovered/report themselves to the browser and which information is available about...

> One possibility is that the enumeration/event only contain a copy of the SensorOptions, since the Sensor itself might involve initializing the peripheral. I've added a start method in prevision...

Our current goal is to make sure the design of the `Sensor` object API, which we'll be shipping first, doesn't clause doors for the discoverability API (which we'll tackle later)...

@pozdnyakov see: https://w3c.github.io/sensors/#identifying-parameters

Agreed, @gmandyam. This was really a note for me so this doesn't get lost. To answer your question, it seems that when the fusion happens at the HW or underlying...

> But we view this more along the lines of what's discussed in issue #4 so that the different sensor data is more closely aligned in time (and also not...

So agreed, @gmandyam. But my point here was to allow Web devs to expose fused sensors of their own with the same API as native ones (in the spirit of...

Reopening this issue following a discussion with @slightlyoff during the W3C TAG review. While the current API absolutely allows building fused sensor in application level code, it is not quite...

Yes. I absolutely agree. The problem is observables are still 2-3 years out, aren't close to consensus and we'd like to ship sensors soon. I'm ready to revisit this if...