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

Draft Minutes from 2016-01-07 teleconference

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Fri, 8 Jan 2016 09:39:36 -0500
To: W3C Device APIs WG <public-device-apis@w3.org>
Message-Id: <47CBDE70-68CE-42DC-9B21-6C8B9444B25C@fjhirsch.com>
Attached are draft minutes from our teleconference yesterday, 2016-01-07. Thanks to Dom for scribing.

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)

www.fjhirsch.com
@fjhirsch


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

# Device APIs Working Group Teleconference

## 07 Jan 2016

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Dom, Tobie_Langel, Anssi_Kostiainen

Regrets


Chair

    Frederick_Hirsch

Scribe

    dom

## Contents

  * [Topics][5]

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

    2. [Minutes approval][7]

    3. [Charter][8]

    4. [Battery Status API][9]

    5. [Generic Sensor API][10]

    6. [Other specs][11]

    7. [Other Business][12]

    8. [Adjourn][13]

  * [Summary of Action Items][14]

  * [Summary of Resolutions][15]

* * *

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

<scribe> ScribeNick: dom

fjh: no particular announcement

... webex issue on hold for now

### Minutes approval

<fjh> [https://lists.w3.org/Archives/Public/public-device-
apis/2016Jan/att-0006/minutes-2015-11-12.html][16]

<anssik> +1

<tobie> +1

**RESOLUTION: Nov 12 minutes approved [https://lists.w3.org/Archives/Public
/public-device-apis/2016Jan/att-0006/minutes-2015-11-12.html][16]**

### Charter

<fjh> Update on charter review, [https://lists.w3.org/Archives/Public/public-
device-apis/2015Dec/0000.html][17]

<fjh> [http://www.w3.org/2015/11/DeviceSensorsCharter.html][18]

<fjh> dom explains [https://lists.w3.org/Archives/Public/public-device-
apis/2016Jan/0005.html][19]

### Battery Status API

fjh: anssi, do you understand where we are with this?

<fjh> Test updates for Firefox update, [https://lists.w3.org/Archives/Public
/public-device-apis/2015Nov/0024.html][20]

<fjh> [https://lists.w3.org/Archives/Public/public-device-
apis/2015Dec/0004.html][21]

fjh: one thing is that Dom needs to update a PR

anssi: our QA folks had some input on this; but I haven't caught up with this

... Dom had made a match to idlharness on which there is pending feedback

<fjh> dom: two discussions, getting idlharness fixed to get promises , but
need to revise my patch, will work on , fairly straightforward

<fjh> dom: in addition, not sure we have interop on battery, so not sure where
that stands

<fjh> fjh: are you able to look at this?

<fjh> anssik: mozilla updated implementation, need to look at edge cases

[https://w3c.github.io/test-results/battery-status/all.html][22]

<fjh> **ACTION:** anssik to review battery failure results and status of
testing [recorded in [http://www.w3.org/2016/01/07-dap-
minutes.html#action01]][23]

<trackbot> Created ACTION-741 - Review battery failure results and status of
testing [on Anssi Kostiainen - due 2016-01-14].

<fjh> **ACTION:** dom to review battery failure results and status of interop
[recorded in [http://www.w3.org/2016/01/07-dap-minutes.html#action02]][24]

<trackbot> Created ACTION-742 - Review battery failure results and status of
interop [on Dominique Hazaël-Massieux - due 2016-01-14].

### Generic Sensor API

Tobie: I'm focusing on solving some of the key problems we discussed last time

... e.g. continuous vs discrete changes

... I'm discussing with Adam Crofts from Auto to discuss how this fits with
their stuff who are having similar issues

<tobie> [https://github.com/w3c/automotive/issues/72][25]

Tobie: we had extensive discussions with them at TPAC; they're interested in
aligning with EventTarget, but they're not sure yet about aligning with the
whole sensor api design yet

... they would like to see how the spec matures before committing to it

... They're hitting similar questions as the ones we're trying to solve

... discussing with them should help figuring how widely our api applies, and
help understanding how the solutions to threshold etc would work

anssi: do they have overlap with "our" sensors? e.g. proximity?

tobie: at this point, I expect they'll prefer to keep spec-ing their sensors
separately

... getting them to align with generic sensor would already be an improvement

... The other aspect is that, even if they also have proximity-like sensors,
their sensors data is transmitted over the car internal network which may lead
to reasonably different model

<fjh> [https://www.w3.org/community/autowebplatform/][26]

-> [http://www.w3.org/2000/09/dbwg/details?group=76043&public=1][27]
Participants in the Automotive Working Group

<tobie> [http://www.w3.org/auto/wg/][28]

<tobie> [https://github.com/w3c/automotive][29]

Frederick: so the big issue is discrete vs continuous (which links to
streaming)

tobie: one thing that isn't clear based on that — how do you combine frequency
polling with event changes

... e.g. it looks like the auto would like to get both a frequency-based polls
AND changes notifications based on values

... not clear what the frequency polling brings in that case -- maybe make
sure the sensor is not disconnected? (if so, it should be notified separately)

... anyway, that's one thing that needs to be figured out; maybe this will
tell us that the generic sensor api is only applicable to "local" sensors?

frederick: the massive amount of data that can be streamed from sensors can
generate storage and transmission costs very quickly

tobie: this all depends on your use case (big data vs "just-on-time" data)

... I'm having a hard time conceptually dividing the API up to make it work
with all use cases, implementation details and sensor specificities

... devices are now shipping sensor hubs that are a lot more power efficient,
with push notifications rather than polling

frederick: so what does it imply for our work in DAP?

... we probably need to narrow our scope to be successful

tobie: exactly! the question is whether the automotive sensors can fit the
same model as the sensors attached to our devices

... if it can, the auto stuff can help us verify our progress; if it can't, we
should be upfront about it

... the same way we have clarified that streaming video isn't in scope for the
generic sensor api

dom: what's the plan in applying generic sensor api to proximity, ambient
lights, possibly device orientation?

tobie: ryu is working on an implementation of ambient lights based on generic
sensor

anssi: we hope to get that out within a couple of months: both a spec update
and the first experimental implementation

... we need to update the ambient lights spec

... having a concrete sensor api will also help explain the scope of the
generic sensor api

frederick: this will affect our milestones obviously; hopefully that won't
hurt us

### Other specs

Frederick: among non-generic sensors API, we need to get moving on wake lock;
I'll check with the editors where this is standing

dom: [I won't be available for calls in February FWIW]

<fjh> fjh: upcoming meeting schedule and minutes can be found here
[http://www.w3.org/2009/dap/minutes.html][30]

### Other Business

<fjh> none

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** anssik to review battery failure results and status of
testing [recorded in [http://www.w3.org/2016/01/07-dap-
minutes.html#action01][31]]

**[NEW]** **ACTION:** dom to review battery failure results and status of
interop [recorded in [http://www.w3.org/2016/01/07-dap-
minutes.html#action02][32]]


## Summary of Resolutions

  1. [Nov 12 minutes approved https://lists.w3.org/Archives/Public/public-
device-apis/2016Jan/att-0006/minutes-2015-11-12.html][33]

[End of minutes]

* * *

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

$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/2016Jan/0004.html

   [4]: http://www.w3.org/2016/01/07-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/2016Jan/att-0006/minutes-2015-11-12.html

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

   [18]: http://www.w3.org/2015/11/DeviceSensorsCharter.html

   [19]: https://lists.w3.org/Archives/Public/public-device-
apis/2016Jan/0005.html

   [20]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Nov/0024.html

   [21]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Dec/0004.html

   [22]: https://w3c.github.io/test-results/battery-status/all.html

   [23]: http://www.w3.org/2016/01/07-dap-minutes.html#action01]

   [24]: http://www.w3.org/2016/01/07-dap-minutes.html#action02]

   [25]: https://github.com/w3c/automotive/issues/72

   [26]: https://www.w3.org/community/autowebplatform/

   [27]: http://www.w3.org/2000/09/dbwg/details?group=76043&public=1

   [28]: http://www.w3.org/auto/wg/

   [29]: https://github.com/w3c/automotive

   [30]: http://www.w3.org/2009/dap/minutes.html

   [31]: http://www.w3.org/2016/01/07-dap-minutes.html#action01

   [32]: http://www.w3.org/2016/01/07-dap-minutes.html#action02

   [33]: #resolution01

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

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












Received on Friday, 8 January 2016 14:40:13 UTC

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