See also: IRC log
<trackbot> Date: 05 March 2015
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Mar/0000.html
<scribe> ScribeNick: fjh
Chrome plan on requiring secure origin for getUserMedia, https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0045.html
gmandyam: had a call a few months ago regarding requiring secure origin as Chair of GeoLocation
… concern that only one browser vendor driving decision, need community decision, will have PING discussion in conjunction with IETF
Approve minutes from 19 February 2015
proposed RESOLUTION: Minutes from 19 February 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/att-0040/minutes-2015-02-19.html
RESOLUTION: Minutes from 19 February 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/att-0040/minutes-2015-02-19.html
fjh: thanks to Zhiqiang and Anssi for driving this forward
Tests and test descriptions updated, https://lists.w3.org/Archives/Public/public-device-apis/2015Feb/0041.html (Zhiqiang)
https://github.com/w3c/web-platform-tests/pull/1623
https://github.com/w3c/web-platform-tests/pull/1644
http://www.w3c-test.org/battery-status/battery-plugging-in-manual.html
the Chrome Android bug of missing an implementation of chargingTime and dischargingTime attributes has been fixed couple of days ago, see: https://crbug.com/401553
fjh: believe Zhiqiang checking that in next release
the Chrome Android bug of missing an implementation of chargingTime and dischargingTime attributes has been fixed couple of days ago, see: https://crbug.com/401553
<anssik> The remaining implementation issues blocking CR exit are
<anssik> * Chrome's lack of WebIDL compliance (http://crbug.com/43394) that causes the battery-interface-idlharness.html and battery-interface.html tests to fail.
<anssik> * Mozilla's implementation update to match the latest spec (https://bugzil.la/1047119).
anssik: test suite is in good shape now
... missing features have been fixed but the WebIDL compliance is still open
fjh: that has not been fixed
anssik: no, it is still in progress, still needs to be fixed, could work around as Dom suggested
… waiting on Firefox compliant implementation
fjh: firefox fix still in progress, yes
anssik: yes, on critical path, someone wanted to work on it in Jan, now has explicit permission to take this on
… mozilla has many volunteers that come and go, asked Marcos if he could do anything to make this move, said enough watching this bug to move it forward
increasing Cordova interest in Battery, contact Dom re sponsoring intern
fjh: anything new
anssik: not yet
waiting for implementations
anssik: also has dependency on Generic Sensor API work, as does Ambient Light, thus expect to revise when Generic Sensor APIs
fjh: so this means that we won’t move existing spec forward
<anssik> http://www.w3.org/2009/dap/#roadmap
<anssik> "Will change based on the current work towards a generic pattern for sensor APIs"
fjh: I believe once we move to generic sensor API I expect this work can move forward fairly quickly, so not necessarily a problem to restart the spec
... need to clarify DAP home page which implies, despite note, that proximity and ambient light are now near completion
anssik: how would we handle process
fjh: go back to FPWD/WD etc since new start
... expect that with implementer support and a generic sensor approach that makes sense I think we can move quickly through the process
… old or new won’t matter much as long as we don’t have re-work cycles, probably doing a LC won’t make much of a difference, need the review anyway
fjh: roughly it sounds like we might have a draft in April, maybe CR in the fall, REC next year, though we might be able to speed it up
fjh: awaiting draft from Tobie who unfortunately is on sick leave
Andrey_Logvinov: in process of implementing it Yandex browser, will then upstream to Chromium
… plan to finish implementation in June then upstream
fjh: when shall we revise standard
Andrey_Logvinov: working off draft, so might find issues that might require revision of spec, otherwise we have a draft
fjh: so if implementation exposes problems good to know before standard work, if ok then we can move draft forward quickly