14:50:57 RRSAgent has joined #dap 14:50:57 logging to http://www.w3.org/2016/01/07-dap-irc 14:50:59 RRSAgent, make logs world 14:50:59 Zakim has joined #dap 14:51:01 Zakim, this will be DAP 14:51:01 I do not see a conference matching that name scheduled within the next hour, trackbot 14:51:02 Meeting: Device APIs Working Group Teleconference 14:51:02 Date: 07 January 2016 14:51:33 Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/0004.html 14:51:38 fjh has changed the topic to: dap https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/0004.html 14:52:01 Chair: Frederick_Hirsch 14:52:04 Present+ Frederick_Hirsch 14:52:42 Topic: Welcome, scribe selection, agenda review, announcements 15:00:15 zakim, this is dap 15:00:15 got it, fjh 15:00:25 zakim, who is here? 15:00:25 Present: Frederick_Hirsch 15:00:27 On IRC I see RRSAgent, fjh, mounir_, dom, tobie, slightlyoff, Josh_Soref, mats, Mek, trackbot 15:00:31 Present+ Dom 15:03:49 anssik has joined #dap 15:03:55 Present+ Tobie_Langel 15:04:03 Present+ Anssi_Kostiainen 15:04:30 ScribeNick: dom 15:05:39 fjh: no particular announcement 15:06:31 ... webex issue on hold for now 15:06:35 Topic: Minutes approval 15:06:59 https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/att-0006/minutes-2015-11-12.html 15:07:25 +1 15:07:28 +1 15:07:32 RESOLVED: Nov 12 minutes approved https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/att-0006/minutes-2015-11-12.html 15:07:46 Topic: Charter 15:07:54 Update on charter review, https://lists.w3.org/Archives/Public/public-device-apis/2015Dec/0000.html 15:07:54 http://www.w3.org/2015/11/DeviceSensorsCharter.html 15:08:24 dom explains https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/0005.html 15:09:40 s/RESOLVED/RESOLUTION/ 15:09:50 Topic: Battery Status API 15:09:58 fjh: anssi, do you understand where we are with this? 15:10:03 Test updates for Firefox update, https://lists.w3.org/Archives/Public/public-device-apis/2015Nov/0024.html 15:10:03 https://lists.w3.org/Archives/Public/public-device-apis/2015Dec/0004.html 15:10:05 ... one thing is that Dom needs to update a PR 15:11:18 anssi: our QA folks had some input on this; but I haven't caught up with this 15:11:35 ... Dom had made a match to idlharness on which there is pending feedback 15:12:02 dom: two discussions, getting idlharness fixed to get promises , but need to revise my patch, will work on , fairly straightforward 15:12:24 dom: in addition, not sure we have interop on battery, so not sure where that stands 15:12:47 fjh: are you able to look at this? 15:13:11 anssik: mozilla updated implementation, need to look at edge cases 15:13:11 https://w3c.github.io/test-results/battery-status/all.html 15:15:13 action: anssik to review battery failure results and status of testing 15:15:14 Created ACTION-741 - Review battery failure results and status of testing [on Anssi Kostiainen - due 2016-01-14]. 15:15:24 action: dom to review battery failure results and status of interop 15:15:29 Created ACTION-742 - Review battery failure results and status of interop [on Dominique Hazaël-Massieux - due 2016-01-14]. 15:16:21 Topic: Generic Sensor API 15:16:35 Tobie: I'm focusing on solving some of the key problems we discussed last time 15:16:45 ... e.g. continuous vs discrete changes 15:17:10 ... I'm discussing with Adam@@@ from Auto to discuss how this fits with their stuff who are having similar issues 15:17:40 https://github.com/w3c/automotive/issues/72 15:17:47 ... 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 15:18:03 ... they would like to see how the spec matures before committing to it 15:18:17 ... They're hitting similar questions as the ones we're trying to solve 15:19:10 ... discussing with them should help figuring how widely our api applies, and help understanding how the solutions to threshold etc would work 15:19:22 anssi: do they have overlap with "our" sensors? e.g. proximity? 15:19:46 tobie: at this point, I expect they'll prefer to keep spec-ing their sensors separately 15:20:10 ... getting them to align with generic sensor would already be an improvement 15:20:54 ... 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 15:21:01 s/Adam@@@/Adam Croft/ 15:21:14 s/Croft/Crofts/ 15:21:14 s/Croft/Crofts/ 15:21:44 https://www.w3.org/community/autowebplatform/ 15:21:50 -> http://www.w3.org/2000/09/dbwg/details?group=76043&public=1 Participants in the Automotive Working Group 15:21:58 http://www.w3.org/auto/wg/ 15:22:11 https://github.com/w3c/automotive 15:22:48 Frederick: so the big issue is discrete vs continuous (which links to streaming) 15:23:22 tobie: one thing that isn't clear based on that — how do you combine frequency polling with event changes 15:23:57 ... e.g. it looks like the auto would like to get both a frequency-based polls AND changes notifications based on values 15:24:31 ... 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) 15:24:54 ... 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? 15:25:19 frederick: the massive amount of data that can be streamed from sensors can generate storage and transmission costs very quickly 15:25:37 tobie: this all depends on your use case (big data vs "just-on-time" data) 15:26:15 ... I'm having a hard time conceptually dividing the API up to make it work with all use cases, implementation details and sensor specificities 15:26:50 ... devices are now shipping sensor hubs that are a lot more power efficient, with push notifications rather than polling 15:27:12 frederick: so what does it imply for our work in DAP? 15:27:39 ... we probably need to narrow our scope to be successful 15:28:21 tobie: exactly! the question is whether the automotive sensors can fit the same model as the sensors attached to our devices 15:28:41 ... if it can, the auto stuff can help us verify our progress; if it can't, we should be upfront about it 15:29:05 ... the same way we have clarified that streaming video isn't in scope for the generic sensor api 15:31:12 q? 15:31:57 dom: what's the plan in applying generic sensor api to proximity, ambient lights, possibly device orientation? 15:32:25 tobie: ryu is working on an implementation of ambient lights based on generic sensor 15:32:57 anssi: we hope to get that out within a couple of months: both a spec update and the first experimental implementation 15:33:11 ... we need to update the ambient lights spec 15:33:29 ... having a concrete sensor api will also help explain the scope of the generic sensor api 15:36:24 frederick: this will affect our milestones obviously; hopefully that won't hurt us 15:36:32 Topic: Other specs 15:36:57 Frederick: among non-generic sensors API, we need to get moving on wake lock; I'll check with the editors where this is standing 15:37:29 [I won't be available for calls in February FWIW] 15:38:27 http://www.w3.org/2009/dap/minutes.html 15:41:41 Topic: Other Business 15:41:41 none 15:41:56 Topic: Adjourn 15:42:01 rrsagent, generate miutes 15:42:01 I'm logging. I don't understand 'generate miutes', fjh. Try /msg RRSAgent help 15:42:07 rrsagent, generate minutes 15:42:07 I have made the request to generate http://www.w3.org/2016/01/07-dap-minutes.html fjh 15:56:40 fjh has joined #dap 16:06:07 fjh has joined #dap 16:58:28 fjh has joined #dap 17:14:11 mats has joined #dap 17:37:06 Zakim has left #dap 19:26:12 fjh has joined #dap 20:01:42 fjh has joined #dap 21:19:42 fjh has joined #dap 21:29:00 fjh has joined #dap 21:38:12 fjh has joined #dap 22:19:46 fjh has joined #dap 22:44:06 fjh has joined #dap 23:04:47 fjh has joined #dap