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

Draft Minutes 12 Jan 2017 teleconference

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 12 Jan 2017 10:52:27 -0500
Message-Id: <73B0D8AB-3720-4C3D-9D7F-BFB81C81F855@fjhirsch.com>
To: W3C Devices and Sensors WG <public-device-apis@w3.org>
Attached are draft minutes from today's DAS teleconference, 12 Jan 2017. Thanks for scribing Dom.

Happy New Years everyone. 

Next call is in two weeks, 26 Jan.

Thanks

regards, Frederick

Frederick Hirsch
Chair, W3C Devices and Sensors WG


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

# Device and Sensors Working Group Teleconference

## 12 Jan 2017

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Andrey_Logvinov, Dominique_Hazael-Massieux, Wanming_Lin,
Tobie_Langel

Regrets

    Anssi_Kostiainen

Chair

    Frederick_Hirsch

Scribe

    dom

## Contents

  * [Topics][5]

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

    2. [Minutes approval][7]

    3. [Shelving Network Service Discovery][8]

    4. [Generic Sensor API][9]

    5. [Wake Lock API][10]

    6. [Generic Sensor API][11]

    7. [Ambient Light][12]

    8. [Adjourn][13]

  * [Summary of Action Items][14]

  * [Summary of Resolutions][15]

* * *

### 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][16]

<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][16]**

### Shelving Network Service Discovery

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

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/][18]

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]][19]

<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/][20]

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][21]

close ACTION-780

<trackbot> Closed ACTION-780.

### Adjourn

## 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][22]]


## 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][23]

[End of minutes]

* * *

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

$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/0001.html

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

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #ActionSummary

   [15]: #ResolutionSummary

   [16]: https://lists.w3.org/Archives/Public/public-device-
apis/2016Dec/att-0007/minutes-2016-12-15.html

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

   [18]: https://w3c.github.io/wake-lock/

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

   [20]: https://infra.spec.whatwg.org/

   [21]: http://www.w3.org/2009/dap/track/actions/780

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

   [23]: #resolution01

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

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



Received on Thursday, 12 January 2017 15:53:07 UTC

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