13:49:59 <RRSAgent> RRSAgent has joined #dap
13:49:59 <RRSAgent> logging to http://www.w3.org/2016/03/17-dap-irc
13:50:01 <trackbot> RRSAgent, make logs world
13:50:01 <Zakim> Zakim has joined #dap
13:50:03 <trackbot> Zakim, this will be DAP
13:50:03 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:50:04 <trackbot> Meeting: Device APIs Working Group Teleconference
13:50:04 <trackbot> Date: 17 March 2016
13:53:14 <dom> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0052.html
13:53:15 <dom> Chair: Dom
13:53:23 <dom> Regrets: Frederick_Hirsch
13:58:34 <Andrey_Logvinov> Andrey_Logvinov has joined #dap
14:02:03 <tobie> present+ Tobie_Langel
14:02:29 <dom> Present+ Dom
14:04:17 <dom> Present+ Anssi_Kostiainen
14:04:41 <anssik> anssik has joined #dap
14:05:47 <anssik> Present+ Anssi_Kostiainen
14:06:08 <dom> Topic: Minutes approval
14:06:32 <Andrey_Logvinov> Present+ Andrey_Logvinov
14:07:16 <dom> RESOLUTION: Minutes from March 3 2016 are approved https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0017.html
14:07:25 <dom> Topic: Battery Status
14:08:08 <anssik> migrated the spec from Hg to Git: https://github.com/w3c/battery -- now accepting PRs!
14:09:23 <dom> Topic: Generic Sensor API
14:10:28 <dom> Tobie: I brought up two weeks ago a question with regard to whether the sensor-poll starting should be split away from creating a new sensor instance
14:10:35 <dom> ... which generated a useful discussion
14:10:51 <dom> ... the split-off helped me make more sense of the intricacies in this space
14:11:17 <dom> ... I completely rebuilt the polyfill I have to be as close as possible to spec language, and am now turning that polyfill into spec language
14:11:28 <dom> ... and consulting people on some of the low-level aspects of the platform
14:11:36 <dom> ... I'm really liking where this is leading
14:11:45 <dom> ... a much more precise description with fewer surprises
14:11:54 <dom> ... but it is taking more time than I had hoped
14:12:14 <dom> ... I was hoping to be done today, but that won't happen; I still need to deal with some corner cases in error handling and time outs
14:12:25 <dom> Anssi: when can we publish?
14:12:54 <dom> Tobie: I chatted with Dom today about this
14:13:00 <dom> ... we can publish as any time
14:13:20 <dom> Dom: indeed, via echidna we can publish despite the starting moratorium
14:13:32 <dom> tobie: some interesting points emerging today
14:13:41 <dom> ... now that we have a start method to start polling the sensor
14:13:59 <dom> ... I kind of like that the state moves from activated to active based on the first reading of the sensor
14:14:12 <dom> ... the question arises when there is an error, what does that mean? it's harder problem than I expected
14:14:28 <dom> ... e.g. if the underlying hardware sends an error, is it a fatal error or not?
14:14:39 <dom> ... AnneVK suggested to wait until we have implementation feedback on the topci
14:14:43 <dom> s/topci/
14:15:20 <dom> ... it could be sensor specific
14:15:41 <dom> Dom: I would guess it is indeed sensor-specific; it probably also depends on the error types as well
14:16:01 <Andrey_Logvinov__> Andrey_Logvinov__ has joined #dap
14:16:35 <dom> tobie: how does that relate to our promise-based flow?
14:16:51 <dom> dom: if the error means that you can't read from the sensor, the promise should be rejected
14:18:04 <dom> tobie: OK, I could see how that would integrate with the algorithm: a fatal error reject the promises, other errors are emitted as error events
14:18:37 <dom> dom: might be confusing to have both error events and promise rejection
14:20:56 <dom> tobie: yeah, but you might need it e.g. if the sensors can't keep up with the requested frequency
14:22:05 <mats> mats has joined #dap
14:22:33 <dom> dom: interesting use case; not clear if there are many such cases or some specific ones that we can put into the generic spec
14:22:57 <dom> ... we can probably tackle fatal errors as a starting point, and see if we need reporting for other type of errors
14:23:14 <dom> tobie: sounds good, will look at that approach
14:23:37 <dom> ... I've opened a few other issues on which I would want feedback
14:23:57 <dom> ... AnneVK suggested that one of the issues should wait for cancelable promises, which sounds reasonable
14:24:20 <dom> ... a recent change in DOM on hires timestamp will simplify our spec
14:25:17 <dom> tobie: will try to push for a draft tomorrow
14:25:32 <dom> Topic: Vibration API
14:26:05 <dom> Anssi: I need to update the spec based on the privacy discussion
14:26:23 <dom> Topic: WakeLock API
14:26:46 <dom> Andrey: I've reviewed the spec against the privacy & security questionnaire
14:26:57 <dom> ... we identified the need to add a privacy & security section to the spec
14:31:19 <dom> RRSAgent, draft minutes
14:31:19 <RRSAgent> I have made the request to generate http://www.w3.org/2016/03/17-dap-minutes.html dom
15:32:25 <mats> mats has joined #dap
16:14:09 <Zakim> Zakim has left #dap
17:46:34 <mats> mats has joined #dap