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 Croftss 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
[I won't be available for calls in February FWIW]
<fjh> http://www.w3.org/2009/dap/minutes.html
<fjh> none
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/RESOLVED/RESOLUTION/ Succeeded: s/Adam@@@/Adam Croft/ Succeeded: s/Croft/Crofts/ Succeeded: s/Croft/Crofts/ Found ScribeNick: dom Inferring Scribes: dom Present: Frederick_Hirsch Dom Tobie_Langel Anssi_Kostiainen Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/0004.html Found Date: 07 Jan 2016 Guessing minutes URL: http://www.w3.org/2016/01/07-dap-minutes.html People with action items: anssik dom[End of scribe.perl diagnostic output]