See also: IRC log
<scribe> ScribeNick: dom
fjh: no particular announcement
... webex issue on hold for now
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/att-0006/minutes-2015-11-12.html
<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
<fjh> Update on charter review, https://lists.w3.org/Archives/Public/public-device-apis/2015Dec/0000.html
<fjh> http://www.w3.org/2015/11/DeviceSensorsCharter.html
<fjh> dom explains https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/0005.html
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
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2015Dec/0004.html
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
<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]
<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]
<trackbot> Created ACTION-742 - Review battery failure results and status of interop [on Dominique Hazaël-Massieux - due 2016-01-14].
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
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/
-> http://www.w3.org/2000/09/dbwg/details?group=76043&public=1 Participants in the Automotive Working Group
<tobie> http://www.w3.org/auto/wg/
<tobie> https://github.com/w3c/automotive
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
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
<fjh> none