[![W3C][1]][2] # Device APIs Working Group Teleconference ## 19 Feb 2015 See also: [IRC log][3] ## Attendees Present Frederick_Hirsch, Giri_Mandyam, Andrey_Logvinov, Dominique_Hazael- Massieux, Anssi_Kostiainen Regrets Chair Frederick_Hirsch Scribe dom, fjh ## Contents * [Topics][4] 1. [Welcome, scribe selection, agenda review, announcements][5] 2. [Minutes approval][6] 3. [VIBRATION API IS a FINE W3C RECOMMENDATION!!!!][7] 4. [HTML Media Capture][8] 5. [Battery API][9] 6. [Wake Lock API][10] 7. [Generic sensor API][11] 8. [Promises and Cordova][12] 9. [Adjourn][13] * [Summary of Action Items][14] * * * Date: 19 February 2015 Agenda: [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0035.html][15] ### Welcome, scribe selection, agenda review, announcements ScribeNick: dom Welcome Dongseong, Intel [https://lists.w3.org/Archives/Public/public- device-apis/2015Feb/0007.html][16] FJH: Andrey, do you want to introduce yourself quickly to the group as a recent participant? Andrey: I'm one of the editors of the wake lock api ... we're interested in developing other APIs for the Web platform FJH: which other APIs? Andrey: another we're developing is around CPU consumption and attribution to a given Web site ... how much a given Web site consumes CPU ... on the client FJH: is that something you would like to add to the charter? is there a draft? Andrey: I'll give you a link FJH: Dongseong from Intel joined us recently — anssi, do you know of his interests? Anssi: mostly on media capture (esp. depth stream) Media Capture TF 2 FPWDs published - Screen Capture, [http://www.w3.org/TR/2015/WD-screen- capture-20150210/][17] Audio Output Devices API [http://www.w3.org/TR/2015/WD-audio- output-20150210/][18] FJH: two FPWD were published recently by the media capture task force FPWD CfC completed - Media Capture from DOM Events, [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0021.html][19] FJH: I'll have to cancel one of our scheduled calls on April 2nd ### Minutes approval Approve minutes from 22 January 2015 [https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/att-0037/minutes-2015-01-22.html][20] proposed RESOLUTION: Minutes from 22 January 2015 are approved **RESOLUTION: Minutes from 22 January 2015 are approved [https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/att-0037/minutes-2015-01-22.html][20]** ### VIBRATION API IS a FINE W3C RECOMMENDATION!!!! Vibration API is W3C Recommendation, [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0024.html][21] FJH: congrats ### HTML Media Capture FJH: tests have been updated Tests updated, please review and run tests; [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0031.html][22] [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0033.html][23] FJH: we need help on running and reviewing tests ... we owe big thanks to Zhiqiang for his work on tests Anssi: I haven't looked at this yet **ACTION:** Dom to review HTML Media Capture tests - due March 12 [recorded in [http://www.w3.org/2015/02/19-dap-minutes.html#action01][24]] Created ACTION-731 - Review html media capture tests [on Dominique Hazaël-Massieux - due 2015-03-12]. Anssi: I'll review them too as editor **ACTION:** Anssi to review html media capture tests [recorded in [http://www.w3.org/2015/02/19-dap-minutes.html#action02][25]] Created ACTION-732 - Review html media capture tests [on Anssi Kostiainen - due 2015-02-26]. ### Battery API The battery test suite has been updated to reflect the latest spec at [https://github.com/w3c/web-platform-tests/issues?q=label%3Abattery- status+is%3Aclosed][26] You can try again the updated tests at [http://www.w3c-test.org/battery- status/][27] See [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0029.html][28] FJH: Zhiqiang has updated the test suite for battery Chrome doesn't support chargingTime and dischargingTime attributes. Issue with test report generation. See [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0030.html][29] FJH: there is a chrome issue about chargingTime/dischargingTime [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0036.html][30] Anssi: there are a idlharness-based tests that fail due to the fact that Chrome doesn't full comply with WebIDL yet ... apart from that, there is another fail due to a bug in Chrome — that hopefully can be fixed (will double check I understood the test correctly) dom, you wanted to talk about WebIDL impl bugs and Rec track stages Anssi: apart from that, we have a conforming impl dom: yes, webidl support is an issue. do you think we can expect a webidl fix in the short term or at all anssik: latest activity was an hour ago, so seems to be in progress anssik: there were some performance regressions so it might take more time even though goal is to get fix in anssik: search with battery-status in logs and you can see specific fixes anssik: believe high on projects agenda given people involved dom: good, so regarding REC track, two options assuming Firefox updated, could wait till bug is solved and tests pass dom: or we give director note that this is well known issue with webidl and chrome and should not impact how this spec is used and interpreted dom: if we do later need to degrade dependency on webidl to be syntactic only. Prefer former personally dom: depends on timing anssik: agree, lets see whether we can get to two implementations FJH: this is a question of timing ... ideally, the WebIDL interpretation will be fixed in Chrome ... when we request to go to PR ... Anssi reports there has been progress, maybe we'll get good news soon ... let's revisit this in ~ 6 weeks Dom: yeah; we need in any case to get the chargingTime bug fixed ... and get the Firefox implementation to align Anssi: there has been a new full time dev associated to this bug in Q1, so that's a positive sign ... but it will land when it is ready, hard to estimate ... but it's not in the way for us now fjh: summary of webidl issue is that specs that use it specify properties that can be supported in an implementation allowing the spec to work, but may not be implemented according to the webidl spec. That could be the basis for progressing the work, however it is better to have a conformant webidl implementation and we will first wait for that to be achieved fjh: is someone helping with Firefox Anssi: I asked about the implementation in Firefox anssik: marcos indicated that people are looking at the bug Anssi: there is some hope that it will move forward ... I'm not sure if the the guy who implemented this works for Mozilla or not ... hard to say if and when this will happen fjh: so webidl clearly isn't a very urgent worry Cordova and Battery API questions, see [https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/0043.html][31] fjh: have not had answer to these dom: had offlist conversation, confirmed concerns dom: not high priority dom: can look to see if can get intern to work on this, google internships program might help dom: if your company is interested in cordova and aligning, there is a work item you could help with; or also you could co-sponsor an intern, please contact Dom if so ### Wake Lock API Wake Lock API published as FPWD, [https://lists.w3.org/Archives/Public /public-device-apis/2015Feb/0032.html][32] dom: auto publish is not activated yet, have to submit dom: later will require conforming to pubrules to publish fjh: want to make sure publishing in TR does not happen with checks dom: checks are done, including validation, pubrules etc. Cannot accidentally post an image of a cat I would like to see the answer to Anssi’s question as well about local install, etc [https://github.com/w3c/echidna][33] [https://lists.w3.org/Archives/Public/spec-prod/2015JanMar/0005.html][34] ### Generic sensor API github issue discussion reflected on w3c public list, [https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0018.html][35] fjh: awaiting update from Tobie Anssi: I talked to Tobie; I hope he'll get bandwidth on this soonish ... hopefully within a month or so ... he's definitely interested in this, but need to be freed from other work before he can start work ... he sounded like he will report back to the group when he makes progress ... great idea to enable the notifications of github issues thanks Dom for creating list notification for github issues Anssi: we have activated the same features in a couple of groups ... it has been very helpful Giri: I think the use cases are still unclear [for sensors?] ... Sensor is much broader than geo where we have found difficult to get vendor support ... I think use cases would help Dom: FWIW, the sensor API is the a generic sensor API ... it's a pattern that can be re-used across the design of several specific sensor API Giri: right; the use cases don't have to be specific to a given sensor, but we need justifications for the choices of a given pattern ... I don't think I have seen that yet ... specific examples on how this would be used in specific vertical use cases would help [https://github.com/w3c/sensors/issues][36] Giri: this would also lead to clear requirements to which we and others can compare developed APIs anssi: the issues identified in existing APIs have been documented as github issues ... this effort is an attempt to fix them through a generic pattern fjh, you wanted to say my sense is sensor API is layered, common basis, then custom specs above common basis anssi: I think the work that has been done in issues is the ground work for use cases and requirements ... I don't know if we want to do the full-blown work of use cases and requirements, or instead a lightweight doc Giri: I think the question is that we need commitments from vendors that are not involved in the day to day activity ... right now the only ref for sensors is an outdated DAP draft ... I've looked at the GH issues FJH: I think publishing an note with the right content would make it much easier for other people to get familiar with our efforts ... I think Giri is right we need to make this more usable Anssi: let's discuss with Tobie how to publish these conclusions once he's around ... it seems reasonable to publish a state of the art FJH: I think publishing it as a note gives it more standing and visibility ... that has merits Anssi: we might have the use cases and requirements as one section of the overall doc that describes the pattern ... that sounds like a plan FJH: Giri is saying we need to get more people on board by stating more clearly what we're trying to do Giri: right; and the standing of the document can help Anssi: Giri, with your Geo chair's hat on, where do we stand on Geo v2, device orientation, and other APIs? ... These APIs should benefit from this work Giri: Geo was narrowly scoped to low power geofencing ... we decided to do that by extending service worker ... there is a pull request to that end in the github repo waiting for editors action ... device orientation is a bit more problematic ... Rich and Tim have done very good work, but we haven't gotten final commitment from the appropriate vendors ... Tim has been trying to see how this fits in terms of the sensor api ... without the commitment of MS and Apple in this group, it's dangerous to try and expand the scope of this work ... my personal inclination is that device orientation stuff be done in the context of this sensor API anssi: thanks, great update giri ... Rich was active on the generic sensor repo ... the discussion confirmed he wanted to get the API to evolve toward this generic pattern Giri: device orientation has a legacy issue with a lot of code depending on it right now ... geofencing doesn't have that issue since it is being built on top of the new serviceworker Anssi: Giri, did you say that device orientation or geo v2 could adopt or be influenced by the sensor work Giri: as far as device orientation is concerned, there are legacy implementations in the browser ... to significantly change the API surface is going to be difficult ... unclear how browser vendors would react to such a change at this point ... a clean break might be a path of least resistance ... For geo, the way we get around this has been to move geofencing to out-of- thread service worker ... leaving the original geo API untouched ... That's not really an option in device orientation ScribeNick: fjh anssik: request that we include geolocation coordination with generic sensor API as part of that discussion fjh: when we have report from Tobie we should include related efforts and impacts ScribeNick: dom ### Promises and Cordova fjh, you wanted to ask about promises [https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/0044.html][37] fjh: the promises issue he mentions is not a specific standardization item for this group, yes dom: yes though it will depend on the degree of linkage with Cordova Anssi: Promises are ecmascript 6 features ... we should not have any worry with them FJH: it's a timing issue Anssi: eventually, when webviews get updated to include modern JS engines ... Webviews are getting better and better fjh: so issue should solve itself Anssi: Time will solve this problem ### Adjourn Thank you dom for scribing thanks all ## Summary of Action Items **[NEW]** **ACTION:** Anssi to review html media capture tests [recorded in [http://www.w3.org/2015/02/19-dap-minutes.html#action02][25]] **[NEW]** **ACTION:** Dom to review HTML Media Capture tests - due March 12 [recorded in [http://www.w3.org/2015/02/19-dap-minutes.html#action01][24]] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][38] version 1.135 ([CVS log][39]) $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/02/19-dap-irc [4]: #agenda [5]: #item01 [6]: #item02 [7]: #item03 [8]: #item04 [9]: #item05 [10]: #item06 [11]: #item07 [12]: #item08 [13]: #item09 [14]: #ActionSummary [15]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0035.html [16]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0007.html [17]: http://www.w3.org/TR/2015/WD-screen-capture-20150210/ [18]: http://www.w3.org/TR/2015/WD-audio-output-20150210/ [19]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0021.html [20]: https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/att-0037/minutes-2015-01-22.html [21]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0024.html [22]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0031.html [23]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0033.html [24]: http://www.w3.org/2015/02/19-dap-minutes.html#action01 [25]: http://www.w3.org/2015/02/19-dap-minutes.html#action02 [26]: https://github.com/w3c/web-platform-tests/issues?q=label%3Abattery- status+is%3Aclosed [27]: http://www.w3c-test.org/battery-status/ [28]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0029.html [29]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0030.html [30]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0036.html [31]: https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/0043.html [32]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0032.html [33]: https://github.com/w3c/echidna [34]: https://lists.w3.org/Archives/Public/spec-prod/2015JanMar/0005.html [35]: https://lists.w3.org/Archives/Public/public-device- apis/2015Feb/0018.html [36]: https://github.com/w3c/sensors/issues [37]: https://lists.w3.org/Archives/Public/public-device- apis/2015Jan/0044.html [38]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [39]: http://dev.w3.org/cvsweb/2002/scribe/