[![W3C][1]][2] # Device APIs Working Group Teleconference ## 04 Feb 2016 [Agenda][3] See also: [IRC log][4] ## Attendees Present Frederick_Hirsch, Giri_Mandyam, Tobie_Langel, Anssi_Kostiainen Regrets Andrey_Logvinov, Dominique_Hazael-Massieux Chair Frederick_Hirsch Scribe fjh ## Contents * [Topics][5] 1. [Welcome, Agenda Review, Scribe Selection][6] 2. [Generic Sensor API][7] 3. [Minutes approval][8] 4. [Battery Status API][9] 5. [Vibration][10] 6. [WakeLock][11] 7. [Other business][12] 8. [Adjourn][13] * [Summary of Action Items][14] * [Summary of Resolutions][15] * * * ### Welcome, Agenda Review, Scribe Selection ScribeNick: fjh ### Generic Sensor API [https://github.com/w3c/sensors/issues/75][16] [https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md][17] should developer care about streaming vs polling type of sensor or should they look the same on change vs continuous fjh: should care if interested in data tobie: depends on use case, e.g for map positioning might not matter ... for geolocation doesn’t matter ... dumb sensors are polled ... smart sensors push fjh: polling with very short time becomes streaming tobie: usually push is enough, can easily replicate as if polled ... doesn’t work for low level access need continuous stream, e.g. virtual reality fjh: auto? giri: everything is interrupt driven on handsets ... streaming or poll choice irrelevant in this case, depends on underlying implementation fjh: consistent API possible giri: different drivers by manufacturer, intellectual property, so not uniform tobie: hardware abstraction layer makes this less important giri: still need to consider what is underneath, e.g Android HAL has not kept up, e.g. depth cameras tobie: depth camera is not in our scope giri: developers need to be aware of limitations ... with respect to frequency returned by sensor tobie: need to understand real developer use cases ... removed everything from spec that IOS and Android could not provide giri: can you tell me what implementation needs to provide, so I can check if it is possible tobie: have checked IOS and Android giri: Qualcomm provides DSP for both IOS and Android tobie: geolocation is easier across platforms ... gyroscope etc are typically polled ... clear cut across platform ... not so clear - heart rate, ambient light, etc not clear whether to poll or stream ... more research required giri: some of these are not integrated into smart phone tobie: implementer does not know giri: are these sensors dynamically discoverable tobie: saving for L2 of spec ... remaining questions - how to present two options to developer in compelling way giri: non-trivial question fjh: next steps? tobie: have proposed set of sensor types, underlying physical sensors, see table [https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md][17] tobie: need reporting mode - on data change or continuous ... if same on Android and IOS can go with that ... checking if we can get same output on both ... look at outstanding issues [https://github.com/w3c/sensors/milestones/Level%201][18] tobie: answered #81, anssik added text ... 79 imposed by platform fjh: can you add proposed resolution for 79 and for 81 tobie: yes ... need to improve language, working on ... just talked about 75 ... 66, need to document properly;y ... 62 punt ... remaining ones require edits to spec and can be closed when done ... last blocker is permissions API ... issue 22 [https://github.com/w3c/sensors/issues/22][19] tobie: nice to have, not must ... adding enums into webIDL ... avoid need to avoid modifying permissions API, but may not get support [https://lists.w3.org/Archives/Public/public-script- coord/2015AprJun/0061.html][20] tobie: discussion was on public-script-coords ... could also use DOMString instead of enum fjh: cannot expect to modify permissions API for every new API tobie: easier to argue once have generic sensor API ... reason against is not to spread enums across specs, makes it hard ... but want permission tied to implementing the sensor fjh: suggest putting it into generic sensor API by default with note explaining rationale ... better to have it there rather than starting without it tobie: yes, good idea ... benefit of DOMString does not require webIDL change ... will do issue cleanup once spec is updated fjh: for issues not from Tobie we need to be able to show resolutions as we move through the process list of issues not opened by editor: [https://github.com/w3c/sensors/i ssues?utf8=%E2%9C%93&q=+is%3Aissue+-author%3Atobie+][21] **ACTION:** fjh to discuss with tobie how to generate report showing issues reported by others and how resolved [recorded in [http://www.w3.org/2016/02/04-dap-minutes.html#action01]][22] Created ACTION-743 - Discuss with tobie how to generate report showing issues reported by others and how resolved [on Frederick Hirsch - due 2016-02-11]. ### Minutes approval Approve minutes from 21 Jan 2016 proposed RESOLUTION: Minutes from 21 Jan 2016 are approved, [https://lists.w3.org/Archives/Public/public-device- apis/2016Jan/att-0062/minutes-2016-01-21.html][23] **RESOLUTION: Minutes from 21 Jan 2016 are approved, [https://lists.w3.org/Archives/Public/public-device- apis/2016Jan/att-0062/minutes-2016-01-21.html][23]** ### Battery Status API fjh: where are we now, including delays on tests anssik: spec gives leeway, so some tests are hard, cannot predict time for test to run to completion, so get some failures ... looking at test results, close to complete now [https://w3c.github.io/test-results/battery-status/all.html][24] fjh: this is much better than before anssik: still have IDL failure related to harness, Dom had patch ... webIDL implementation issues ... total of 4 failures in both of two implementations fjh: will need Dom’s help ... what is yellow anssik: manual tests ... tobie do you know what yellow means tobie: not sure ... but think so ... undefined - means was not run anssik: does this tool even work with manual tests fjh: need to clarify what bottom of table means anssik: yes, can do this. But China new year starts Monday **ACTION:** anssik to clarify battery test report , removing or explaining yellow at bottom of report [recorded in [http://www.w3.org/2016/02/04-dap-minutes.html#action02]][25] Created ACTION-744 - Clarify battery test report , removing or explaining yellow at bottom of report [on Anssi Kostiainen - due 2016-02-11]. ### Vibration fjh: Clarification errata item, ISSUE-171 ... first need proposal for change, then CfC for agreement, then update Errata and do PER ... Focus should be on agreement to change then mechanics to get it done ### WakeLock fjh: remaining issues are here [https://github.com/w3c/wake-lock/issues][26] ... looks like these need to be resolved. ... defer discussion ### Other business fjh: none ### Adjourn ## Summary of Action Items **[NEW]** **ACTION:** anssik to clarify battery test report , removing or explaining yellow at bottom of report [recorded in [http://www.w3.org/2016/02/04-dap-minutes.html#action02][27]] **[NEW]** **ACTION:** fjh to discuss with tobie how to generate report showing issues reported by others and how resolved [recorded in [http://www.w3.org/2016/02/04-dap-minutes.html#action01][28]] ## Summary of Resolutions 1. [Minutes from 21 Jan 2016 are approved, https://lists.w3.org/Archives/Public/public-device- apis/2016Jan/att-0062/minutes-2016-01-21.html][29] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][30] version 1.144 ([CVS log][31]) $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/2016Feb/0017.html [4]: http://www.w3.org/2016/02/04-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://github.com/w3c/sensors/issues/75 [17]: https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md [18]: https://github.com/w3c/sensors/milestones/Level%201 [19]: https://github.com/w3c/sensors/issues/22 [20]: https://lists.w3.org/Archives/Public/public-script- coord/2015AprJun/0061.html [21]: https://github.com/w3c/sensors/issues?utf8=%E2%9C%93&q=+is%3Aissue+-a uthor%3Atobie+ [22]: http://www.w3.org/2016/02/04-dap-minutes.html#action01] [23]: https://lists.w3.org/Archives/Public/public-device- apis/2016Jan/att-0062/minutes-2016-01-21.html [24]: https://w3c.github.io/test-results/battery-status/all.html [25]: http://www.w3.org/2016/02/04-dap-minutes.html#action02] [26]: https://github.com/w3c/wake-lock/issues [27]: http://www.w3.org/2016/02/04-dap-minutes.html#action02 [28]: http://www.w3.org/2016/02/04-dap-minutes.html#action01 [29]: #resolution01 [30]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [31]: http://dev.w3.org/cvsweb/2002/scribe/