W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2017

[admin] Draft minutes 26 January 2017

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 26 Jan 2017 11:07:47 -0500
Message-Id: <3A12C9AA-78AC-4031-9E16-640B79BC301F@fjhirsch.com>
To: W3C Devices and Sensors WG <public-device-apis@w3.org>
Attached are draft minutes from today's call, 26 January 2017. Much thanks to Dom for scribing.

As discussed on the call, in the spirit of publish early and often, we will put out an updated WD of Generic Sensor API, even though more change is expected. Thanks Tobie for all your work on this spec and Mikhail for your feedback.

Welcome back Anssi.

Next call is 9 Feb.

regards, Frederick

Frederick Hirsch
Chair, W3C Devices and Sensors WG


[![W3C][1]][2]

# Device and Sensors Working Group Teleconference

## 26 Jan 2017

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Dominique_Hazael-Massieux, Andrey_Logvinov,
Tobie_Langel, Anssi_Kostiainen, Lukasz_Olejnik, Mikhail_Pozdnyakov

Regrets


Chair

    Frederick_Hirsch

Scribe

    dom

## Contents

  * [Topics][5]

    1. [Welcome, scribe selection, agenda review, announcements][6]

    2. [Minutes approval][7]

    3. [Generic Sensor API][8]

    4. [Concrete Sensors][9]

    5. [Wake Lock][10]

    6. [Battery][11]

    7. [Vibration][12]

    8. [Other Business][13]

    9. [Adjourn][14]

  * [Summary of Action Items][15]

  * [Summary of Resolutions][16]

* * *

### Welcome, scribe selection, agenda review, announcements

<scribe> ScribeNick: dom

<fjh> The WG Note marking the shelving of Network Service Discovery has been
published: [https://www.w3.org/TR/2017/NOTE-discovery-api-20170112/][17]

<fjh> Now have weekly digest of GitHub activity (thanks Dom)

<fjh> [https://lists.w3.org/Archives/Public/public-device-
apis/2017Jan/0007.html][18]

<fjh> reminder public-device-apis-log mail list is very useful

[https://lists.w3.org/Archives/Public/public-device-apis-log/][19]

### Minutes approval

<fjh> Approve minutes from 12 January 2017

<fjh> [https://lists.w3.org/Archives/Public/public-device-
apis/2017Jan/att-0004/minutes-2017-01-12.html][20]

<fjh> proposed RESOLUTION: Minutes from 12 January 2017 are approved

**RESOLUTION: Jan 12 2017 minutes approved
[https://lists.w3.org/Archives/Public/public-device-
apis/2017Jan/att-0004/minutes-2017-01-12.html][20]**

### Generic Sensor API

fjh: lots of issues closed on generic sensor, great progress

... could you summarize the status?

Tobie: I've been catching up on a lot of the conversations we've had in the
couple of weeks

... assessing input and learning from implementations

... and figuring out the best route forward

... I rewrote a big bunch of the spec, closing a bunch of issues

... there was so much to consider at the same time that doing it piecemeal
would have been a lot of work without clear added value except for papertrail

... in the process of doing that, and thanks to Alex and Mikhail's input

... I identified a number of open questions / issues which I've put in-line in
the spec

... will maybe move them to github, but not sure that's the best option yet

... this leaves us with:

... * a number of areas in the spec that need editorial work (cleanup, better
examples, etc)

... * a bunch of very specific questions around very specific issues, mainly
regarding how the data from the sensors passes through the JS boundaries and
when

... what I've learned from the Chromium implementation is an interesting
strategy to coupling it with requestAnimationFrame

... which seems to make a lot of sense and solves a number of problems, as
well as clear open questions e.g. re 120Hz polling

... with e.g. the possibility in a later version of the spec to buffer
readings prior to delivery

... I need to check that this actually solves the use cases that we were
providing with

... and see with implementors if that strategy makes sense and if it is
applicable across platforms

... it helps answer questions also around periodic reporting mode

... and be more precise about how we spec the tiny details of how this
actually work

... that's for the high level stuff

<anssik> Level 1 open issues now down to 9:
[https://github.com/w3c/sensors/milestone/2][21]

Tobie: I also did a lots of small changes to the spec to address some of the
security / privacy issues

... but there still needs to be clean up

fjh: what's the outcome on garbage collection? what about permissions?

Tobie: good questions

... I need to open an issue around "bring your own buffer"

... with regard to permissions, Anssi noted that we're kind of out of sync
with the permission spec

... I have a bunch of concerns around permissions

... mainly that the spec isn't moving very fast nor answering a bunch of
questions we have to answer

... and it's not at the top of the priority list of its lead editor Jeffrey

... the spec is at a stage where it's good enough for them

... it sort of works for us but not in the best possible way

... I'm also waiting for feedback from the Chromium security team

... which will provide valuable feedback esp from the UI implementation
perspective

... With regard to garbage collection, the big revamp of the spec fixes this -

... one missing piece is for values that need to be passed by reference, have
a "bring-your-own-buffer" mechanism

... which I want to align with other specs that have similar needs

... I think we have that need e.g. for motion sensors with
matrices/quaternions

fjh: it might be useful to make an explicit note on GC design in the spec

Tobie: good point

fjh: what about the TAG?

Tobie: The TAG had reviewed and sent a bunch of comments on the spec

... we should probably ping them once the spec stabilizes again

... I want to improve the spec based on the implementations experience which
will be a massive boost to the spec quality in terms of precision

... I would like that in before getting the TAG to review it again

... also, I'm much more confident in writing this more precisely with my
WebIDL editor experience

[https://tabatkins.github.io/bikeshed/#cli-echidna][22]

fjh: should we publish an updated WD?

Tobie: probably

Dom: +1 ; publish early & often

<fjh> +1

Dom: see [https://tabatkins.github.io/bikeshed/#cli-echidna][22] in how to
publish with bikeshed

Anssi: [blasting standardization pace]

<fjh> well now Anssi is back, so the progress will speed up

<anssik> +1 to publish an updated WD as soon as possible

<fjh> publish updated WD now

Tobie: there is a pattern of use of reading data in requestAnimationFrame
which lets us have higher frequency than rAF without having some of the issues
of having too much data

... the distinction between capturing data at a given frequency vs reading
that data from JS

... is a nice way to think about this problem space

... the work is now to put that into spec form

Dom: what's our timeline for new TAG review and then possibly CR transition?

Tobie: it will depends on the feedback on permission/security from Chrome team

... and input from implementors on the overall design

... and feedback on high level frequency

Dom: another way to look at this is what's the plans from implementors?

Anssi: next step for Chromium will be origin-trials - no committed timeline at
the moment

... also, we need to synchronize the spec with implementation

<fjh> note origin trials means only white listed sites can use the API

Mikhail: there are still pretty gaps with the onchange behavior

... I also noticed the new state called "unconnected"

tobie: yes, I had to add this - there was implementation feedback that the
default sensor could not be figured out synchronously

... the object needed a special state

... if there are better ideas of a name, I'd be interested

Mikhail: undefined?

... I've also more questions on the state machine - this state can never be
reached again?

Tobie: I'm not super attached to the current state machine if there are
reasons to do that

Mikhail: if you call start, and there is no sensor what's the next state?

Tobie: it should be "errored"

... first state is not connected to hardware, then connecting, then connected

... if at any point there is a fatal error, you move to errored

... otherwise, if you stop it, you move to idle

... (connected but not polling)

### Concrete Sensors

<anssik> Gyro adapted [https://github.com/w3c/gyroscope/pull/10][23]

Anssi: Mikhail started adapting the gyro API to the updated generic sensor

Mikhail: I moved the reading to the sensor interface itself

Anssi: tobie, will you be adapting Ambient Light to the new Generic Sensor?

Tobie: good idea

... I can also look at the Gyro pull request to make sure it's aligned

Anssi: from what I understand from Mikhail, the adaption was fairly
straightforward

Mikhail: the procedure for reading in Generic Sensor is using internally a Map
- what does it mean in practice?

<anssik> [https://infra.spec.whatwg.org/#ordered-map][24]

Tobie: I think that this matches the buffer you have in the implementation

... it's probably one single map per sensor per origin

... that just stores the data that is read from the sensor itself

... and it is updated at every requestAnimationFrame

... and all the concrete sensor instances just get the value from it

... it's an abstract object

... I'm relying on the Infra spec

... it's an abstract data structure that all the instances tap into

... probably need to do a diagram of how this all works

<fjh> Mikhail: will open some other detailed issues

Tobie: the feeling I have is the more precise we are, the better, but we also
need to avoid being too specific - we need to find where the put the cursor in
specificity and would love to get your feedback on that

<fjh> tobie: or make pull requests

### Wake Lock

fjh: Dom was to ping that TAG to get an updated review

... and maybe discuss some of the respec issues

Dom: pinged them, not heard back yet

fjh: Anssi, is there a way you could help Andrey with the new warnings from
respec?

<anssik> [https://github.com/w3c/respec/wiki/data-dfn-for][25]

<anssik> see also [https://github.com/w3c/respec/wiki/WebIDL-Guide][26]

Anssi: the pointer above explains the issue

... ReSpec is more agressive in requiring prose for each and every WebIDL item

Dom: feel free to ping me Andrey if you're still not finding your way

<fjh> moving forward with implementation would be useful to learn, depends on
if TAG feedback would result in rework

Andrey: does it make sense for me to move with implementation? or should we
wait for feedback?

Dom: implementation experience would be helpful for the spec

... but it depends on how much implementation efforts you can afford without
certainty

<fjh> suggest we get a slot on the TAG agenda for Wake Lock

<fjh> best way to get attention

fjh: would be good if this could move up earlier rather than later on the TAG
agenda

<fjh> **ACTION:** fjh to ask TAG to put Wake Lock on agenda [recorded in
[http://www.w3.org/2017/01/26-dap-minutes.html#action01]][27]

<trackbot> Created ACTION-784 - Ask tag to put wake lock on agenda [on
Frederick Hirsch - due 2017-02-02].

Dom: not sure how to do that - maybe ask nicely from chair to chairs? >:)

<Andrey_Logvinov> [https://github.com/w3ctag/spec-
reviews/issues/126#issuecomment-257137369][28]

### Battery

fjh: Battery - we're waiting for more implementation - but how long should we
wait?

Anssi: the current status is that Mozilla unshipped it, but Chrome and other
derivative browsers are shipping it

<anssik> [http://caniuse.com/#search=battery][29]

<anssik> expand with show all

Anssi: Chrome, Opera, Opera Mobile, Android Browser, Chrome Mobile, UC,
Samsung Internet ships it

... given the mobile focus, Firefox dropping it is not having much impact from
a market share perspective

<anssik> [https://crbug.com/661792][30]

Anssi: For Chromium, there is an open issue opened by lukasz

... which has been assigned to Tim Volodine

... latest update in December

... as a result, I think it's still a bit premature to make a decision

... there may be integration with permission API as the result, which may
allow Firefox to ship it again

<fjh> dom: two views of future, only Chromium & derivatives ship, then do not
fulfil 2 implementations expectation, have to decide if that is good enough,
or stop the spec

<fjh> dom: another view is that more work brings Firefox back

<fjh> dom: agree, don’t need to make assessment now, but probably need to
think through our approach

<anssik> [https://developer.microsoft.com/en-us/microsoft-
edge/platform/status/batterystatusapi/][31]

Anssi: Edge has it "under consideration"

<anssik> [https://developer.microsoft.com/en-us/microsoft-edge/platform/status
/batterystatusapi/?q=sort%3AVotes%20edge%3A%27Under%20Consideration%27][32]

Dom: when should we re-evaluate this?

anssi: the issue doesn't seem very high priority from the Chromium perspective
(P3)

Dom: maybe check back in a month or two and re-evaluate then?

fjh: I'd say 2 or 3 months

### Vibration

Anssi: no particular update, just editorial work

### Other Business

<fjh> Thanks everyone

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** fjh to ask TAG to put Wake Lock on agenda [recorded in
[http://www.w3.org/2017/01/26-dap-minutes.html#action01][33]]


## Summary of Resolutions

  1. [Jan 12 2017 minutes approved https://lists.w3.org/Archives/Public
/public-device-apis/2017Jan/att-0004/minutes-2017-01-12.html][34]

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][35] version 1.144 ([CVS
log][36])

$Date: 2015/11/17 08:39:34 $

   [1]: https://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Jan/0008.html

   [4]: http://www.w3.org/2017/01/26-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #ActionSummary

   [16]: #ResolutionSummary

   [17]: https://www.w3.org/TR/2017/NOTE-discovery-api-20170112/

   [18]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Jan/0007.html

   [19]: https://lists.w3.org/Archives/Public/public-device-apis-log/

   [20]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Jan/att-0004/minutes-2017-01-12.html

   [21]: https://github.com/w3c/sensors/milestone/2

   [22]: https://tabatkins.github.io/bikeshed/#cli-echidna

   [23]: https://github.com/w3c/gyroscope/pull/10

   [24]: https://infra.spec.whatwg.org/#ordered-map

   [25]: https://github.com/w3c/respec/wiki/data-dfn-for

   [26]: https://github.com/w3c/respec/wiki/WebIDL-Guide

   [27]: http://www.w3.org/2017/01/26-dap-minutes.html#action01]

   [28]: https://github.com/w3ctag/spec-
reviews/issues/126#issuecomment-257137369

   [29]: http://caniuse.com/#search=battery

   [30]: https://crbug.com/661792

   [31]: https://developer.microsoft.com/en-us/microsoft-
edge/platform/status/batterystatusapi/

   [32]: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/
batterystatusapi/?q=sort%3AVotes%20edge%3A%27Under%20Consideration%27

   [33]: http://www.w3.org/2017/01/26-dap-minutes.html#action01

   [34]: #resolution01

   [35]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [36]: http://dev.w3.org/cvsweb/2002/scribe/



Received on Thursday, 26 January 2017 16:08:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC