Re: [sensors] Introduce WebDriver extension API

> Consider the single HTTP request is the most common scenario and more
> acceptable. (People might be confuse to use javascript function to send a
> single request)

I'm reluctant to make design decisions based on the most common scenario of
today because we only have the experience of Chromium implementers to draw
from. Web developers will have distinct needs (other implementers may, too),
and they are a sizable audience for this API. All the more reason to get more
web devs involved!

> How about keep single set of readings as current solution, and extend this
> section by using WebDriver's "execute script" command to script complex sets
> of readings?

That could be a nice simplification, but I don't think the current text
supports it. There doesn't seem to be an JavaScript API to control this, so
the code that developers provide via "Execute Script" doesn't have an interface
to specify mock values.

We could define such a JavaScript API, but that might not be necessary.
Developers may stub out the JavaScript constructor of the device they wish to
mock. Their stub constructor could generate instances which emitted events in
whatever sequence they liked. This just requires injecting code prior to the
evaluation of their application. For some configurations, that could be a
little cumbersome but not impossible. [I've filed an issue against WebDriver to
discuss making this easier.](https://github.com/w3c/webdriver/issues/1293)

If that is a tenable solution, then maybe web developers aren't an audience for
this feature, after all! What do you think?

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

Received on Wednesday, 22 August 2018 19:16:08 UTC