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

# Device APIs Working Group Teleconference

## 03 Sep 2015

See also: [IRC log][3]

## Attendees

Present

    Andrey_Logvinov, Anssi_Kostiainen, Dapeng_Liu, Dominique_Hazael-Massieux,
Frederick_Hirsch, Giri_Mandyam, Tobie_Langel

Regrets


Chair

    Frederick_Hirsch

Scribe

    fjh, dom

## Contents

  * [Topics][4]

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

    2. [Device Orientation][6]

    3. [Minutes approval][7]

    4. [Charter revision][8]

    5. [Battery][9]

    6. [Generic Sensor Use Cases][10]

    7. [Generic Sensor API update][11]

    8. [Wake lock API][12]

    9. [Other Specs][13]

    10. [Actions][14]

    11. [Summary][15]

    12. [Adjourn][16]

  * [Summary of Action Items][17]

* * *

<trackbot> Date: 03 September 2015

<fjh> Agenda: [https://lists.w3.org/Archives/Public/public-device-
apis/2015Aug/0021.html][18]

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

<fjh> ScribeNick: fjh

fjh: the /TR style sheet response sent: [https://lists.w3.org/Archives/Public
/public-device-apis/2015Jul/0021.html][19]

... I submitted the style sheet response

... TPAC reminder (no DAP F2F): [http://www.w3.org/2015/10/TPAC/][20]

... who will be leading breakout session at TPAC

anssik: I will be there, expect Tobie as well, Giri you might wish to join

[Note - moved Device Orientation discussion to its own topic

fjh: Welcome to new members: Dapeng Liu, Rong Zhang (Alibaba), Rijubrata
Bhaumik (Intel), Alexandra Mikityuk (Deutsche Telekom), Josh Soref (IE)

... Viacom has also joined (no participant)

dom: need to look into this

fjh: participants list -
[http://www.w3.org/2000/09/dbwg/details?group=43696&public=1&order=org][21]

dapeng: from Alibaba group, working in standards group

... interested in all of the work of this group

fjh: do you plan to contribute to implementation and testing

dapeng: no plans yet, but would like to help with testing

anssi: Rijubrata contributing to Chromium, working on browser code, will be
implementing some of the sensor APIs

fjh: Proximity and Ambient Light Event API WDs published, with warning that
moving toward generic sensor API

[https://lists.w3.org/Archives/Public/public-device-
apis/2015Sep/0002.html][22]

### Device Orientation

giri: put out call for future information on device orientation, got no
response

... Rich left Opera

... should close issue

anssik: will device orientation move

giri: first want LC, but Apple still not compliant so an issue

... need LC first

... this does not stop revising device orientation under the generic sensor
API

tobie: have looked over the last two weeks looking at device orientation to
get sense for use cases for generic sensor API

dom: geolocation WG had no objection to DAP taking over device orientation so
we should add to charter

<anssik> +1

fjh: +1

<tobie> +1

### Minutes approval

Approve minutes from 25 June 2015

proposed RESOLUTION: Minutes from 25 June 2015 are approved,
[https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/att-0175/minutes-2015-06-25.html][23]

**RESOLUTION: Minutes from 25 June 2015 are approved,
[https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/att-0175/minutes-2015-06-25.html][23]**

### Charter revision

[https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/0149.html][24]

created diff [http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2
011%2F07%2FDeviceAPICharter&doc2=http%3A%2F%2Fw3c.github.io%2Fdap-
charter%2FDeviceAPICharter.html][25]

<anssik> [http://w3c.github.io/dap-charter/DeviceAPICharter.html][26]

<dom> [https://github.com/w3c/dap-charter/issues][27]

fjh: There is a pull request regarding licensing

[https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/0003.html][28]

fjh: Please review the charter

dom: if there are new work items to add, now is a good time to do so

... would like to finailize the charter by the end of this month

... please look at the charter, look at the open issues, consider new items
that should be added to the charter

### Battery

fjh: Draft updated for privacy considerations:
[https://lists.w3.org/Archives/Public/public-device-
apis/2015Aug/0011.html][29]

... thanks Anssi for updating draft for privacy consideration

... Mozilla update, need for test harness update?

[https://lists.w3.org/Archives/Public/public-device-
apis/2015Aug/0018.html][30]

fjh: test harness does not handle promises

anssi: yes idl harness needs to be updated, sent mail, awaiting response,
could work around it

fjh: follow up with James next week?

anssi: they need to figure it out

### Generic Sensor Use Cases

<dom> ScribeNick: dom

<tobie> [http://w3c.github.io/sensors/usecases.html][31]

tobie: basically, we came to the conclusion a couple of weeks ago that it was
hard to get to consensus on the exact API design

... because they were hard to express in WebIDL

... I realized that having code examples based on use cases would help

... the idea of the use cases doc is to document real-world applications
related to sensor work

... and also look at building polyfills for existing APIs

... I've worked on two such apps based on GH discussions

<tobie> [http://w3c.github.io/sensors/examples/realtime-
positioning/index.html][32]

tobie: the first one is real time positioning on a map using geolocation

... it's not completely finished but it already brought me to interesting
conclusions on sensor frequency

... one of the keys is to try to minimize the battery consumption

... so you need some indication on how often the sensor should be probed

giri: we have had agreement for device orientation

... built on sensor api

... I don't think there is such an agreement for geolocation

... not sure my company would agree to it

... we can use it as a use case, but I don't want us to commit to move geo to
this model

tobie: good point

anssi: there can always be a polyfill in any case

... and it informs our design

fjh: right; but we should make clear that we're not saying geo will move to
that model

[an issue will be raised in github to track this]

tobie: there has been a bunch of issues raised on generic sensors based on the
experience with the geolocation API

... that's why I started looking at it in more details

... example of issues include accessing cached data

<tobie> [http://w3c.github.io/sensors/examples/cached-data/index.html][33]

tobie: the 2nd example is in fact based on this cached data aspect

... combined with looking at the battery level

<fjh> suggest adding note that says that geolocation is included as use case
to better understand generic model but does not imply that standard work will
move the Geolocation WG or to imply that the standard will be changed at this
time.

fjh: so this document is not just text, it also has working code

tobie: indeed; there are also separate links to each app

... I'm not convinced yet this is the best format for the end document, but it
is good way to present this right now

... I then spent a lot of time on devising an app for head tracking based on
device orientation api

... it proved to be very complicated

... I found an interesting paper from occulus that might help; will give
another go at it next week

... head tracking is one of the most cross-sensors type of app you can do in
an app right now

<fjh> side comment - not sure I like privacy invasive technologies, head
tracking might be one of those

tobie: also spent time on device orientation

... I'm looking for a couple of extra use cases that touch on other aspects
beyond these

... I'm hoping to have something ready to be published as a FPWD for our next
call

fjh: some of our existing work on proximity or ambient light could be added

tobie: right; I'm not as familiar with these but I can take a look

dom: so FPWD 2 weeks from now - do you think we would publish it with or
without the live apps?

tobie: I don't know; I think it's cool to have them in, but have no strong
opinions

fjh: if we have them in, there might be issues with the publication process

dom: I'll need to look ahead of time to see if we want them in or not

tobie: another approach would be to have screenshots instead of live apps

anssi: yes, with links to the demo apps

... also, we should add more code snippets to contrast the approaches

tobie: yes, that's the goal: more code, explanations

... I'm happy to replace live apps with screenshots and links

fjh: are we talking about being ready for FPWD two weeks from now?

tobie: yes

anssi: sounds like a plan!

[amazing agreement all over]

### Generic Sensor API update

tobie: my goal is to use the use cases to come to agreement as to what works
and what doesn't

... that's the main issue right now to move forward

... the output of the use cases work will be direct input to the generic
sensor api work

... my current hope is to get to FPWD-ready for the API 4 weeks from now

... that might be optimistic, but I'll use that as a target

### Wake lock API

<fjh> status - [https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/att-0000/00-part][34]

<fjh> (from [https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/0000.html)][35]

fjh: not aware of news on that one

Andrey: we updated the spec to move the wake lock request attribute from
document to the Screen interface

... the implementation of the wake lock api has landed in Blink

... and the Chromium part is waiting for review

fjh: what should be our next steps?

andrey: we should update the WD to reflect the editors draft

fjh: can we use the simplified publication process?

dom: yes; we could even do that automatically

andrey: that'd be good

<fjh> **ACTION:** dom to update current WD of Wake Lock and set it up so WD is
updated automatically when ED updated [recorded in
[http://www.w3.org/2015/09/03-dap-minutes.html#action01][36]]

<trackbot> Created ACTION-738 - Update current wd of wake lock and set it up
so wd is updated automatically when ed updated [on Dominique Hazaël-Massieux -
due 2015-09-10].

dom: ok, I'll look into both publishing an update and set up the automation

<fjh> fjh: how are we notified about updates to WD

dom: I'll look into it

<fjh> dom: home page news should be updated first time

### Other Specs

<fjh> no news

### Actions

<fjh> [removed mistaken paste of action list]

<fjh> Anssi please review your and Ziquiang actions and close those that you
can.

<fjh> Gir please review your action and close if done

<fjh> see [https://www.w3.org/2009/dap/track/actions/open][37]

<fjh> ACTION-735?

<trackbot> ACTION-735 -- Anssi Kostiainen to Create editor drafts for ambient
light and proximity indicating new approach toward generic sensor api, also
drafts for publication to tr space -- due 2015-07-02 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/735][38]

<fjh> close ACTION-735

<trackbot> Closed ACTION-735.

<fjh> ACTION-736?

<trackbot> ACTION-736 -- Frederick Hirsch to Send cfc for wd publication for
ambient light and proximity once drafts available -- due 2015-07-02 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/736][39]

<fjh> close ACTION-736

<trackbot> Closed ACTION-736.

### Summary

<fjh> Plan is to have updated Generic Sensor API Use Cases document ready
before call in next two weeks, to discuss and then publish FPWD

<fjh> Plan is also to publish updated WD of Wake Lock API and to arrange
automatic WD updates when ED updated.

<fjh> Dom to look into how WG is notified when automatic WD updates occur.

<fjh> Thanks to everyone for productive call, especially Tobie for preparing
generic sensor use cases, Anssi for WD publications, Dom for scribing!

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** dom to update current WD of Wake Lock and set it up so
WD is updated automatically when ED updated [recorded in
[http://www.w3.org/2015/09/03-dap-minutes.html#action01][36]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][40] version 1.135 ([CVS
log][41])

$Date: 2009-03-02 03:52:20 $

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

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

   [3]: http://www.w3.org/2015/09/03-dap-irc

   [4]: #agenda

   [5]: #item01

   [6]: #item02

   [7]: #item03

   [8]: #item04

   [9]: #item05

   [10]: #item06

   [11]: #item07

   [12]: #item08

   [13]: #item09

   [14]: #item10

   [15]: #item11

   [16]: #item12

   [17]: #ActionSummary

   [18]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Aug/0021.html

   [19]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/0021.html

   [20]: http://www.w3.org/2015/10/TPAC/

   [21]: http://www.w3.org/2000/09/dbwg/details?group=43696&public=1&order=org

   [22]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Sep/0002.html

   [23]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/att-0175/minutes-2015-06-25.html

   [24]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/0149.html

   [25]: http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2011%2
F07%2FDeviceAPICharter&doc2=http%3A%2F%2Fw3c.github.io%2Fdap-
charter%2FDeviceAPICharter.html

   [26]: http://w3c.github.io/dap-charter/DeviceAPICharter.html

   [27]: https://github.com/w3c/dap-charter/issues

   [28]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/0003.html

   [29]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Aug/0011.html

   [30]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Aug/0018.html

   [31]: http://w3c.github.io/sensors/usecases.html

   [32]: http://w3c.github.io/sensors/examples/realtime-positioning/index.html

   [33]: http://w3c.github.io/sensors/examples/cached-data/index.html

   [34]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/att-0000/00-part

   [35]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jul/0000.html)

   [36]: http://www.w3.org/2015/09/03-dap-minutes.html#action01

   [37]: https://www.w3.org/2009/dap/track/actions/open

   [38]: http://www.w3.org/2009/dap/track/actions/735

   [39]: http://www.w3.org/2009/dap/track/actions/736

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

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