Re: [sensors] Introduce WebDriver extension API

> @jugglinmike, wow! Really appreciate for such elaborate comments!

My pleasure :)

> So we should "set the new mock sensor reading to .." instead of "invoking
> update latest reading" and define what is new mock sensor reading. Does it
> make sense to you?

I wasn't aware of Chromium's implementation; thanks for the background! It sounds
like what I'm proposing is fundamentally more powerful than that, though.

An application developer might write some code to respond to a rapid increase
in brightness. To test their application logic using this new WebDriver API,
they'd need to simulate the increase via a series of POST requests:

    POST /session/c0ffee/sensor/ambient-light
    {"illuminance": 0}
    POST /session/c0ffee/sensor/ambient-light
    {"illuminance": 0.2}
    POST /session/c0ffee/sensor/ambient-light
    {"illuminance": 0.4}
    POST /session/c0ffee/sensor/ambient-light
    {"illuminance": 0.6}
    POST /session/c0ffee/sensor/ambient-light
    {"illuminance": 0.8}
    POST /session/c0ffee/sensor/ambient-light
    {"illuminance": 1}

However, they won't have any control over when those values get applied.
Depending on network effects, this could be not very rapid at all (and not very
smooth as a result). It will also get more cumbersome for more expressive
sensors (e.g. gyroscope) and for more complex readings (e.g. a "twist"
movement). And since all WebDriver commands execute in series, developers won't
be able to interact with the browser while this is happening.

If instead, the automation API allowed developers to specify a function, they
could express an entire series of sensor readings that was arbitrarily complex
and continuous, and they could do it with a single POST request.

Here's how it might look with a "classic" function body that received the time
offset as its first argument:

    POST /session/c0ffee/sensor/ambient-light
    {
      "body": "const t = arguments[0]; return {illuminance: Math.min(t / 1000, 1)};"
    }

And here's a fancier version using an ES2015 generator function that tracks the
time with its own internal state:

    POST /session/c0ffee/sensor/ambient-light
    {
      "body": "const start = performance.now(); while (true) { const t = performance.now() - start; yield {illuminance: Math.min(t / 1000, 1)}; }"
    }

The latter is more verbose for this example, but the ability to maintain state
could make it much easier to script complex sets of readings.

-- 
GitHub Notification of comment by jugglinmike
Please view or discuss this issue at https://github.com/w3c/sensors/pull/369#issuecomment-414760073 using your GitHub account

Received on Tuesday, 21 August 2018 17:41:03 UTC