Device and Sensors Working Group Teleconference

12 Jan 2017


See also: IRC log


Frederick_Hirsch, Andrey_Logvinov, Dominique_Hazael-Massieux, Wanming_Lin, Tobie_Langel


Welcome, scribe selection, agenda review, announcements

<scribe> ScribeNick: dom

<fjh> dom: have activated github digest notifications into list, nobody needs to do anything special

Minutes approval

<fjh> Approve minutes from 15 December 2016

<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Dec/att-0007/minutes-2016-12-15.html

<fjh> proposed RESOLUTION: Minutes from 15 December 2016 are approved

RESOLUTION: Minutes from 15 December 2016 are approved https://lists.w3.org/Archives/Public/public-device-apis/2016Dec/att-0007/minutes-2016-12-15.html

Shelving Network Service Discovery

<fjh> CfC to shelve completed - https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0000.html

Frederick: CfC completed, WG Note published, home page updated

Generic Sensor API

Frederick: probably nothing worth discussing without Tobie on the call
... Tobie was planning to do a bunch of work based on the garbage collection issue that was raised

Wake Lock API

Dom: reviewed

Andrey: and merged
... I have started the implementation of the new API in Chromium

Dom: should we ping the TAG to let them know about the refactoring of the API

Andrey: yes

<fjh> https://w3c.github.io/wake-lock/

Dom: I'll ping them, putting Andrey in the loop

<scribe> ACTION: Dom to let the TAG know about the updated Wake Lock spec [recorded in http://www.w3.org/2017/01/12-dap-minutes.html#action01]

<trackbot> Created ACTION-783 - Let the tag know about the updated wake lock spec [on Dominique Hazaël-Massieux - due 2017-01-19].

Andrey: note that ReSpec has been updated, raising new warnings

Dom: indeed; my other WG has been affected too; a bit annoyed by that change
... but can help fixing bugs if anybody needs help

close ACTION-782

<trackbot> Closed ACTION-782.

Generic Sensor API

Tobie: had a long meeting with the Intel implementors on Tuesday
... goal is to release generic sensor, ambient light and the motion sensors in the main Chrome version pretty soon
... which means I need fixing lots of stuff pretty quickly
... we identified 4 areas that need work:
... - garbage collection (which is leading to large API change, hopefully by tomorrow)
... - open privacy & security issues that need non-normative additions (no clear timeframe)
... - the permission model - but the editor has been on paternity leave, and there are still a lot of fluctuations in it
... right now you have to add permissions to the main permission api, which isn't great, but not sure we can avoid it for now
... - reporting mode issue which we discussed last time
... there are disagreements and lack of clarity on whether there are or will be "push" sensors in shipping devices
... which might affect whether or not and when developers can set the reporting mode
... also, there are platforms that make it difficult or impossible to expose sensors properly to developers
... hoping to tackle those next week, with lots of write-ups
... Google Devrel has started to make quite a bit of promotion on generic sensor api
... want to talk with him to see if he can connect me with developers that have strong requirements around this
... but I first need a solid write up

Frederick: not sure I fully understand the push issue
... is that a sensor changing under you in how it reports its data?

Tobie: there are a number of aspects
... I wrote the spec with the goal of shipping a level 1 with a framework on which we can build in the future
... and that provides an equivalent feature set to existing sensors API (a la device orientation)
... and fixes the known issues of these APIs
... one of these issues is to be able to read sensor data immediately, without having to wait for its value to have an initial change
... and another was to allow setting the polling frequency
... Now that led me to design an API with 2 reporting models: periodic - for sensors that support it, you'll get back data at the said frequency; ua-dependent - let implementors provide data as it sees fits, typically only when data changes
... the latter allowing important battery saving

Frederick: I'm hearing not all sensors / use cases are the same, and thus need different APIs
... how can we manage this under a single API?

Tobie: the polling frequency use cases are strictly useful for the motion sensor API

Frederick: so the generic sensor supports both, and concrete sensors pick one?

Tobie: more specifically, concrete sensors need to specify whether they support periodic or not
... maybe this could be exposed more distinctly than a simple parameter - will need to think about it
... in any case, I'm getting feedback that all sensors should allow poll-based reporting
... my issue is that this prevents battery optimizations
... I guess "frequency" could be a hint rather than a setting
... if a hint, it would be down to developers to determine if that provides the needed accuracy for their use case
... In general, the more we can make decisions at the level of the generic sensor, the better both writing concrete specs and keeping them consistent
... Another point worth mentioning: there is a new whatwg spec - infra - that specifies a number of abstract data structures

<tobie> https://infra.spec.whatwg.org/

Tobie: it makes it easier to spec things consistently
... I'm relying on a bunch of things specified in there
... (ordered lists, ordered maps)
... it helps with using a consistent terminology and algorithms

Frederick: so priority is garbage collection right?

tobie: yes
... bringing a really large spec change
... then it will be much easier to close a number of smaller issues

Frederick: how are we doing on the security/privacy sections? we had volunteers to help?

Tobie: yes, so far, it's mostly about threat models which will lead to non-normative additions to the specs
... e.g. keylogging via accelerometer

Frederick: how can others help you?

Tobie: I need to get back into the spec now
... I'll then write up executive summaries of known issues to look for solid feedback from TAG, developers
... similar to the feedback we got on garbage collection

Ambient Light

<fjh> ACTION-780?

<trackbot> ACTION-780 -- Dominique Hazaël-Massieux to Accept pull request for ambient light -- due 2016-12-08 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/780

close ACTION-780

<trackbot> Closed ACTION-780.


<fjh> s/rrsagent, gnerate minues//

<fjh> s’s/rrsagent, gnerate minues//‘’

Summary of Action Items

[NEW] ACTION: Dom to let the TAG know about the updated Wake Lock spec [recorded in http://www.w3.org/2017/01/12-dap-minutes.html#action01]

Summary of Resolutions

  1. Minutes from 15 December 2016 are approved https://lists.w3.org/Archives/Public/public-device-apis/2016Dec/att-0007/minutes-2016-12-15.html
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/12 15:44:47 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/atm/now/
Succeeded: s/GC/garbage collection/
FAILED: s/rrsagent, gnerate minues//
Found ScribeNick: dom
Inferring Scribes: dom
Present: Frederick_Hirsch Andrey_Logvinov Dominique_Hazael-Massieux Wanming_Lin Tobie_Langel
Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0001.html
Found Date: 12 Jan 2017
Guessing minutes URL: http://www.w3.org/2017/01/12-dap-minutes.html
People with action items: dom

[End of scribe.perl diagnostic output]