Re: [sensors] Introduce WebDriver extension API

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

> **Sampling frequency** By allowing users to set the minSamplingFrequency and maxSamplingFrequency, we are giving them a way to influence the sampling frequency. These constraints are useful for platform sensors which varying physical limitations. There are no such constraints in this case, though. What do you think about exposing the "sampling frequency" directly? That would give users more control over the behavior of their mock devices.

I am fine on exposing the "sampling frequency" directly, but Chromium Layout tests have [tests](https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/LayoutTests/sensor/resources/generic-sensor-tests.js#134) for minSamplingFrequency and maxSamplingFrequency, @rakuco, @alexshalamov, WDYT?

>**Readings** Speaking as a web developer, think this API may not be powerful enough to thoroughly test my applications. Unless I am mistaken, the API requires a POST request for each new sensor reading I want to simulate. In many cases, I may not be able (or willing) to issue HTTP requests at an acceptable rate, especially if the remote end is running over the Internet (maybe via a third party like Sauce Labs).

I may made a mistake here, my thought was making the new sensor reading always be the value from invoking "Update mock sensor reading" command, thus the mock sensor will always expose the same reading, which is what chromium mock sensor implemented. 

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?

> "**Interception**" We could partially address it with non-normative text in the definition of "connect to sensor" ("Note: the result of this algorithm may be intercepted in automated scenarios."), but that would still be treating it as somehow less relevant than the mainline algorithm. Even better would be to extend the algorithm itself, coarsely "1. If MockSensorConfiguration/connected is set, return true."

I was also with concern when I used "Interceptor".  I don't have a better idea, @rakuco, @anssiko, do you have any input?


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

Received on Tuesday, 21 August 2018 09:47:29 UTC