W3C home > Mailing lists > Public > public-device-apis-log@w3.org > September 2018

Re: [sensors] Introduce WebDriver extension API

From: jugglinmike via GitHub <sysbot+gh@w3.org>
Date: Wed, 05 Sep 2018 22:06:53 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-418897218-1536185212-sysbot+gh@w3.org>
> I will leave with "mock sensor reading" only,

Cool!

>  I'm not sure place it in an algorithm is appropriate, what's your opinion?

By way of example, check out the first step of [the "Activate a sensor object" algorithm](https://w3c.github.io/sensors/#activate-a-sensor-object):

> 1. Let *sensor* be the [platform sensor](https://w3c.github.io/sensors/#concept-platform-sensor) associated with *sensor_instance*.

A concrete sensor is stored in a variable, and the "platform censor" *concept* is only referenced to describe the variable's type.

Compare this to the following steps in "Create mock sensor":

> 3. Run these sub-steps [in parallel](https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel) to create a [mock sensor](#mock-sensor) in [current browsing context](https://w3c.github.io/webdriver/webdriver-spec.html#dfn-current-browsing-context):
>    1. Set the [mock sensor’s type](#mock-sensor-type) to *type*.

In the phrase, "the mock sensor's type," the term "mock sensor" refers to a mock sensor that hasn't been created. What I have in mind is something like this:

> 3. Run these sub-steps [in parallel](https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel) to create a [mock sensor](#mock-sensor) in [current browsing context](https://w3c.github.io/webdriver/webdriver-spec.html#dfn-current-browsing-context):
>    1. Let *mock* be a new [mock sensor](#mock-sensor).
>    2. Set *mock*’s [mock sensor type](#mock-sensor-type) to *type*.

Does that sound right to you?

> do you think we need to create an internal slots similar to the [Sensor internal slots](https://w3c.github.io/sensors/#sensor-internal-slots) to store properties like mock sensor type, minSamplingFrequency, maxSamplingFrequency, and etc..

To be honest, this is pushing my understanding of spec conventions. I *think* that because these values are not exposed to JavaScript, it's unnecessary to use internal slots. In this case, it may be enough to add text like, "A mock sensor has an associated mock sensor type [...]". The other reviewers can probably answer this question definitively.

-- 
GitHub Notification of comment by jugglinmike
Please view or discuss this issue at https://github.com/w3c/sensors/pull/369#issuecomment-418897218 using your GitHub account
Received on Wednesday, 5 September 2018 22:07:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 September 2018 22:07:00 UTC