Should sensor EventTarget be immediately available or should they be accessed through a promise?

[tobie]

@timvolodine advocates getting at the sensor object (the EventTarget instance) through a promise so it is already primed with data when first accessed. That has benefits and drawbacks compared to @rwaldron's proposal (which provides the sensor object immediately, but with null values for the data properties).

Worth discussing this in relationship to feature detection (#5) and defensive programming (might be necessary to guard against the sensor being suddenly disconnected anyway).

Proposed resolution: The Generic Sensor API inherits from the EventTarget interface and cannot itself be constructed. Specific sensor objects will need to inherit from the Generic Sensor interface.

There remains disagreement as to how these specific interfaces should be instantiated. Resolving that disagreement implies understanding the performance constraints, feature detection and discoverability issues(see #7), and the API design concerns (consistency, exposing primitives, etc.).

Actions:

• Research what information about sensors is available when navigating a new resource and what kind needs to be requested asynchronously.
• Eliminate API proposals that are blocking.
• Search for other areas of the platform with similar constraints and see what solutions were devised. Consider consistency.
• List common usage patterns (including production-level error handling) and compare the quality of the code produced using the different API proposals.

[tobie]

Note @rwaldron's syntax comparison in the original issue:

Illustrative example (from @timvolodine's proposal)

Example 2 (using requestAnimationFrame):

var sensor = null;
function updateFrame() {
  window.requestAnimationFrame(updateFrame);
  if (sensor)
    console.log(sensor.currentOrientation);
  // do something else
}

navigator.getDeviceOrientationSensor(“high”).then(
  function(orientationSensor){ sensor = orientationSensor; },
  function() { console.log("error"); });

window.requestAnimationFrame(updateFrame);

Would be written as:

var orientation = new sensors.Orientation({ frequency: 200 });

function updateFrame() {
  window.requestAnimationFrame(updateFrame);
  if (orientation.value)
    console.log(orientation.value);
  // do something else
}

window.requestAnimationFrame(updateFrame);

[borismus]

Polling the sensor individually has performance drawbacks, since you need to re-enter JS context very often. Suppose you're polling a gyroscope at 1000 Hz for really good head tracking (eg. Oculus does this). If the application allows it, it's obviously more efficient is getting batches of events (eg. 100 values every 10 seconds). The callback/promises approach allows this, sensor polling doesn't.

[tobie]

Polling the sensor individually has performance drawbacks, since you need to re-enter JS context very often. Suppose you're polling a gyroscope at 1000 Hz for really good head tracking (eg. Oculus does this). If the application allows it, it's obviously more efficient is getting batches of events (eg. 100 values every 10 seconds).

I'm not sure I understand this properly. Are these two different use case you're describing (Oculus and another app that would log movements but not need realtime processing)?

The callback/promises approach allows this, sensor polling doesn't.

I'm confused about that as well, as both proposals use an EventTarget, the sync/async issue being only about how to retrieve said EventTarget.

[borismus]

I'm not sure I understand this properly. Are these two different use case you're describing (Oculus and another app that would log movements but not need realtime processing)?

Let me rephrase: even if you're doing realtime processing (eg. say at 60 Hz), there is a benefit to having more than one new value every time you process (eg. say sensor runs at 1000 Hz). In this case, every time you process, you'll have [1000/60] ~= 16 new sensor data.

use an EventTarget

My concern is alleviated if the polling API stores some configurable amount of historical sensor data.

[tobie]

I'm not sure I understand this properly. Are these two different use case you're describing (Oculus and another app that would log movements but not need realtime processing)?

Let me rephrase: even if you're doing realtime processing (eg. say at 60 Hz), there is a benefit to having more than one new value every time you process (eg. say sensor runs at 1000 Hz). In this case, every time you process, you'll have [1000/60] ~= 16 new sensor data.

That seems like a valid use case. Tracking here: #13

[rwaldron]

Re: the OP...

Initializing the sensor instance via a promise overcomplicates cases where application code needs to initialize a set of sensor objects based on some declarative data, eg. some user preference specific features. In our current proposal, a reference to the sensor instance is immediately available, which means it's ready for arbitrary operations (eg. put into a registry of sensors being monitored). The opposing proposal takes away this capability.

[tobie]

@rwaldron I think we should list different scenarios, write up solutions with both syntaxes, than objectively compare.

[rwaldron]

+1

[richtr]

Re: the OP...

Initializing the sensor instance via a promise overcomplicates cases where application code needs to initialize a set of sensor objects based on some declarative data, eg. some user preference specific features.

In our current proposal, a reference to the sensor instance is immediately available, which means it's ready for arbitrary operations (eg. put into a registry of sensors being monitored). The opposing proposal takes away this capability.

The potential with returning immediately as per the current proposal is that these objects may not connect to any underlying sensor hardware and/or may never deliver any sensor data changes. I do not see how maintaining references to such objects that are effectively dead-on-arrival is a desirable feature.

[tobie]

I do not see how maintaining references to such objects that are effectively dead-on-arrival could be a useful feature.

It's not. But that doesn't mean it might not be the right tradeoff to make.

[rwaldron]

If the sensor doesn't actually exist or the implementation is dummy and produces no readings, the properties that produce the sensor values will always be null and change events will never occur—those are strong metrics for feature/support detection, while still allowing sane construction of sensor objects.

[rwaldron]

The spec must also make ample use of normative MUST for all of these aspects. Underspecification and loose implementation allowances (ie. Using "should") will be chaotic.

[tobie]

Various comments in #8 are related to this conversation, notably around the opportunity of being able to fallback from highly specific sensor subclasses (e.g. BlindSpotProximitySensor) to more generic ones (e.g. ProximitySensor) in case where the specificity of a sensor could only be defined as it sends data. TBH, I'm not sold on why we'd be able to know a sensor is of the ProximitySensor type without accessing it but wouldn't be able to know it's more precisely a BlindSpotProximitySensor until actually accessing it. @richtr?

[tobie]

Proposed resolution: The Generic Sensor API inherits from the EventTarget interface and cannot itself be constructed. Specific sensor objects will need to inherit from the Generic Sensor interface.**

There remains disagreement as to how these specific interfaces should be instantiated. Resolving that disagreement implies understanding the performance constraints, feature detection and discoverability issues(see #7), and the API design concerns (consistency, exposing primitives, etc.).

Actions:

• Research what information about sensors is available when navigating a new resource and what kind needs to be requested asynchronously.
• Eliminate API proposals that are blocking.
• Search for other areas of the platform with similar constraints and see what solutions were devised. Consider consistency.
• List common usage patterns (including production-level error handling) and compare the quality of the code produced using the different API proposals.

[tobie]

We're splitting up the API here between EventTarget sensor that can be constructed independently and a discoverability API that won't land until Level 2.