14:39:48 <RRSAgent> RRSAgent has joined #dap
14:39:48 <RRSAgent> logging to http://www.w3.org/2017/01/26-dap-irc
14:39:50 <trackbot> RRSAgent, make logs world
14:39:50 <Zakim> Zakim has joined #dap
14:39:52 <trackbot> Zakim, this will be DAP
14:39:52 <Zakim> ok, trackbot
14:39:53 <trackbot> Meeting: Device and Sensors Working Group Teleconference
14:39:53 <trackbot> Date: 26 January 2017
14:51:11 <Andrey_Logvinov> Andrey_Logvinov has joined #dap
14:51:15 <fjh> fjh has changed the topic to: das agenda https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0008.html
14:51:20 <fjh> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0008.html
14:51:41 <fjh> Chair: Frederick_Hirsch
14:51:55 <fjh> Present+ Frederick_Hirsch
14:52:13 <fjh> Topic: Welcome, scribe selection, agenda review, announcements
14:53:47 <fjh> Present+ Dominique_Hazael-Massieux
14:59:48 <Andrey_Logvinov> Present+ Andrey_Logvinov
15:01:20 <dom> ScribeNick: dom
15:04:29 <dom> Present+ Tobie_Langel
15:04:35 <anssik> anssik has joined #dap
15:04:36 <dom> Present+ Anssi_Kostiainen
15:04:53 <fjh> The WG Note marking the shelving of Network Service Discovery has been published: https://www.w3.org/TR/2017/NOTE-discovery-api-20170112/
15:05:04 <fjh> Now have weekly digest of GitHub activity (thanks Dom)
15:05:05 <fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0007.html
15:05:42 <fjh> reminder public-device-apis-log mail list is very useful
15:05:47 <dom> https://lists.w3.org/Archives/Public/public-device-apis-log/
15:06:31 <dom> Topic: Minutes approval
15:06:35 <fjh> Approve minutes from 12 January 2017
15:06:35 <fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0004/minutes-2017-01-12.html
15:06:36 <fjh> proposed RESOLUTION: Minutes from 12 January 2017 are approved
15:06:51 <dom> RESOLVED: Jan 12 2017 minutes approved https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0004/minutes-2017-01-12.html
15:06:56 <dom> Topic: Generic Sensor API
15:07:07 <dom> FJH: lots of issues closed on generic sensor, great progress
15:07:13 <dom> ... could you summarize the status?
15:07:26 <dom> Tobie: I've been catching up on a lot of the conversations we've had in the couple of weeks
15:07:38 <dom> ... assessing input and learning from implementations
15:07:45 <dom> ... and figuring out the best route forward
15:08:05 <dom> ... I rewrote a big bunch of the spec, closing a bunch of issues
15:08:29 <fjh> q+ to ask about garbage collection and permissions
15:08:33 <dom> ... there was so much to consider at the same time that doing it piecemeal would have been a lot of work without clear added value except for papertrail
15:08:52 <dom> ... in the process of doing that, and thanks to Alex and Michail's input
15:09:09 <dom> ... I identified a number of open questions / issues which I've put in-line in the spec
15:09:23 <dom> ... will maybe move them to github, but not sure that's the best option yet
15:09:28 <dom> ... this leaves us with:
15:09:48 <dom> ... * a number of areas in the spec that need editorial work (cleanup, better examples, etc)
15:10:18 <dom> ... * a bunch of very specific questions around very specific issues, mainly regarding how the data from the sensors passes through the JS boundaries and when
15:10:41 <dom> ... what I've learned from the Chromium implementation is an interesting strategy to coupling it with requestAnimationFrame
15:11:14 <dom> ... which seems to make a lot of sense and solves a number of problems, as well as clear open questions e.g. re 120Hz polling
15:11:36 <dom> ... with e.g. the possibility in a later version of the spec to buffer readings prior to delivery
15:11:58 <dom> ... I need to check that this actually solves the use cases that we were providing with
15:12:15 <dom> ... and see with implementors if that strategy makes sense and if it is applicable across platforms
15:12:29 <dom> ... it helps answer questions also around periodic reporting mode
15:12:43 <dom> ... and be more precise about how we spec the tiny details of how this actually work
15:12:48 <dom> ... that's for the high level stuff
15:13:04 <anssik> Level 1 open issues now down to 9: https://github.com/w3c/sensors/milestone/2
15:13:08 <dom> ... I also did a lots of small changes to the spec to address some of the security / privacy issues
15:13:13 <dom> ... but there still needs to be clean up
15:13:19 <fjh> q?
15:13:42 <dom> FJH: what's the outcome on garbage collection? what about permissions?
15:13:46 <dom> Tobie: good questions
15:13:52 <fjh> q+ to ask about TAG, time to review
15:13:58 <dom> ... I need to open an issue around "bring your own buffer"
15:14:16 <dom> ... with regard to permissions, Anssi noted that we're kind of out of sync with the permission spec
15:14:22 <dom> ... I have a bunch of concerns around permissions
15:14:35 <dom> ... mainly that the spec isn't moving very fast nor answering a bunch of questions we have to answer
15:14:48 <dom> ... and it's not at the top of the priority list of its lead editor Jeffrey
15:15:22 <dom> ... the spec is at a stage where it's good enough for them
15:15:31 <dom> ... it sort of works for us but not in the best possible way
15:15:41 <dom> ... I'm also waiting for feedback from the Chromium security team
15:16:02 <dom> ... which will provide valuable feedback esp from the UI implementation perspective
15:16:30 <dom> ... With regard to garbage collection, the big revamp of the spec fixes this -
15:16:52 <dom> ... one missing piece is for values that need to be passed by reference, have a "bring-your-own-buffer" mechanism
15:17:00 <dom> ... which I want to align with other specs that have similar needs
15:17:23 <dom> ... I think we have that need e.g. for motion sensors with matrices/quaternions
15:17:42 <dom> FJH: it might be useful to make an explicit note on GC design in the spec
15:17:48 <dom> Tobie: good point
15:17:52 <fjh> q?
15:18:07 <dom> FJH: what about the TAG?
15:18:08 <fjh> q-
15:18:23 <dom> Tobie: The TAG had reviewed and sent a bunch of comments on the spec
15:18:33 <dom> ... we should probably ping them once the spec stabilizes again
15:18:58 <fjh> q?
15:19:28 <dom> ... I want to improve the spec based on the implementations experience which will be a massive boost to the spec quality in terms of precision
15:19:38 <dom> ... I would like that in before getting the TAG to review it again
15:19:57 <dom> ... also, I'm much more confident in writing this more precisely with my WebIDL editor experience
15:21:44 <dom> https://tabatkins.github.io/bikeshed/#cli-echidna
15:22:51 <dom> FJH: should we publish an updated WD?
15:23:00 <dom> Tobie: probably
15:23:09 <dom> Dom: +1 ; publish early & often
15:23:17 <fjh> +1
15:23:21 <dom> ... see https://tabatkins.github.io/bikeshed/#cli-echidna in how to publish with bikeshed
15:23:30 <dom> Anssi: [blasting standardization pace]
15:23:50 <fjh> well now Anssi is back, so the progress will be speed up
15:23:57 <fjh> s/be //
15:24:22 <anssik> +1 to publish an updated WD as soon as possible
15:24:37 <fjh> publish updated WD  now
15:24:39 <dom> Tobie: there is a pattern of use of reading data in requestAnimationFrame which lets us have higher frequency than rAF without having some of the issues of having too much data
15:25:24 <dom> ... the distinction between capturing data at a given frequency vs reading that data from JS
15:26:34 <dom> ... is a nice way to think about this problem space
15:26:46 <dom> ... the work is now to put that into spec form
15:26:49 <fjh> Q?
15:27:43 <dom> Dom: what's our timeline for new TAG review and then possibly CR transition?
15:27:57 <dom> Tobie: it will depends on the feedback on permission/security from Chrome team
15:28:15 <dom> ... and input from implementors on the overall design
15:28:21 <dom> ... and feedback on high level frequency
15:29:17 <dom> Dom: another way to look at this is what's the plans from implementors?
15:29:37 <dom> Anssi: next step for Chromium will be origin-trials - no committed timeline at the moment
15:29:48 <dom> ... also, we need to synchronize the spec with implementation
15:29:51 <fjh> note origin trials means only white listed sites can use the API
15:30:18 <dom> Michail: there are still pretty gaps with the onchange behavior
15:30:45 <dom> ... I also noticed the new state called "connected"
15:31:03 <dom> tobie: yes, I had to add this - there was implementation feedback that the default sensor could not be figured out synchronously
15:31:31 <dom> ... the object needed a special state
15:31:45 <dom> s/connected/unconnected/
15:31:54 <Andrey_Logvinov> Andrey_Logvinov has joined #dap
15:31:57 <dom> ... if there are better ideas of a name, I'd be interested
15:32:06 <dom> Michail: undefined?
15:32:25 <anssik> s/Michail/Mikhail/
15:32:45 <dom> ... I've also more questions on the state machine - this state can never be reached again?
15:32:46 <dom> s/Michail/Mikhail/g
15:33:07 <dom> Tobie: I'm not super attached to the current state machine if there are reasons to do that
15:33:21 <dom> Mikhail: if you call start, and there is no sensor what's the next state?
15:33:26 <dom> Tobie: it should be "errored"
15:33:44 <dom> ... first state is not connected to hardware, then connecting, then connected
15:33:57 <dom> ... if at any point there is a fatal error, you move to errored
15:34:03 <dom> ... otherwise, if you stop it, you move to idle
15:34:13 <dom> ... (connected but not polling)
15:34:34 <dom> Topic: Concrete Sensors
15:34:43 <anssik> Gyro adapted https://github.com/w3c/gyroscope/pull/10
15:35:08 <dom> Anssi: Mikhail started adapting the gyro API to the updated generic sensor
15:35:28 <dom> Mikhail: I moved the reading to the sensor interface itself
15:35:46 <dom> Anssi: tobie, will you be adapting Ambient Light to the new Generic Sensor?
15:35:52 <dom> Tobie: good idea
15:36:03 <dom> ... I can also look at the Gyro pull request to make sure it's aligned
15:36:29 <dom> Anssi: from what I understand from Mikhail, the adaption was fairly straightforward
15:36:58 <dom> Mikhail: the procedure for reading in Generic Sensor is using internally a Map - what does it mean in practice?
15:36:58 <anssik> https://infra.spec.whatwg.org/#ordered-map
15:37:13 <dom> Tobie: I think that this matches the buffer you have in the implementation
15:37:24 <dom> ... it's probably one single map per sensor per origin
15:37:35 <dom> ... that just stores the data that is read from the sensor itself
15:37:42 <dom> ... and it is updated at every rAF
15:37:51 <dom> ... and all the concrete sensor instances just get the value from it
15:38:03 <dom> ... it's an abstract object
15:38:05 <fjh> s/rAF/received animation frame/
15:38:10 <dom> ... I'm relying on the Infra spec
15:38:21 <dom> s/received animation frame/requestAnimationFrame
15:38:38 <dom> ... it's an abstract data structure that all the instances tap into
15:38:52 <dom> ... probably need to do a diagram of how this all works
15:40:58 <fjh> Mikhail: will open some other detailed issues
15:41:07 <dom> ... the feeling I have is the more precise we are, the better, but we also need to avoid being too specific - we need to find where the put the cursor in specificity and would love to get your feedback on that
15:41:15 <fjh> tobie: or make pull requests
15:41:34 <dom> Topic: Wake Lock
15:41:51 <dom> FJH: Dom was to ping that TAG to get an updated review
15:41:55 <dom> ... and maybe discuss some of the respec issues
15:42:16 <dom> Dom: ping them, not heard back yet
15:42:39 <dom> FJH: Anssi, is there a way you could help Andrey with the new warnings from respec?
15:42:45 <anssik> https://github.com/w3c/respec/wiki/data-dfn-for
15:43:09 <anssik> see also https://github.com/w3c/respec/wiki/WebIDL-Guide
15:43:26 <dom> Anssi: the pointer above explains the issue
15:43:42 <dom> ... ReSpec is more agressive in requiring prose for each and every WebIDL item
15:43:54 <dom> Dom: feel free to ping me Andrey if you're still not finding your way
15:44:03 <fjh> s/ping them/pinged them/
15:45:02 <fjh> moving forward with implementation would be useful to learn, depends on if TAG feedback would result in rework
15:45:22 <dom> Andrey: does it make sense for me to move with implementation? or should we wait for feedback?
15:45:34 <dom> Dom: implementation experience would be helpful for the spec
15:46:01 <dom> ... but it depends on how much implementation efforts you can afford without certainty
15:46:48 <fjh> suggest we get a slot on the TAG agenda for Wake Lock
15:46:55 <fjh> best way to get attention
15:47:03 <dom> FJH: would be good if this could move up earlier rather than later on the TAG agenda
15:47:15 <fjh> action: fjh to ask TAG to put Wake Lock on agenda
15:47:15 <trackbot> Created ACTION-784 - Ask tag to put wake lock on agenda [on Frederick Hirsch - due 2017-02-02].
15:47:16 <dom> Dom: not sure how to do that - maybe ask nicely from chair to chairs? >:)
15:47:43 <Andrey_Logvinov> https://github.com/w3ctag/spec-reviews/issues/126#issuecomment-257137369
15:48:21 <dom> Topic: Battery & Vibration
15:48:35 <dom> FJH: Battery - we're waiting for more implementation - but how long should we wait?
15:48:56 <dom> Anssi: the current status is that Mozilla unshipped it, but Chrome and other derivative browsers are shipping it
15:49:21 <anssik> http://caniuse.com/#search=battery
15:49:27 <anssik> expand with show all
15:49:31 <dom> ... Chrome, Opera, Opera Mobile, Android Browser, Chrome Mobile, UC, Samsung Internet ships it
15:50:24 <dom> ... given the mobile focus, Firefox dropping it is not having much impact from a market share perspective
15:50:33 <anssik> https://crbug.com/661792
15:50:43 <dom> ... For Chromium, there is an open issue opened by lukasz
15:50:53 <dom> ... which has been assigned to Tim Volodine
15:51:08 <dom> ... latest update in December
15:51:20 <dom> ... as a result, I think it's still a bit premature to make a decision
15:51:52 <dom> ... there may be integration with permission API as the result, which may allow Firefox to ship it again
15:52:46 <fjh> dom: two views of future, only Chromium & derivatives ship, then do not fulfil 2 implementations expectation, have to decide if that is good enough, or stop the spec
15:52:58 <fjh> dom: another view is that more work brings Firefox back
15:53:17 <fjh> dom: agree, don’t need to make assessment now, but probably need to think through our approach
15:53:18 <anssik> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/batterystatusapi/
15:53:31 <dom> Anssi: Edge has it "under consideration"
15:53:48 <anssik> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/batterystatusapi/?q=sort%3AVotes%20edge%3A%27Under%20Consideration%27
15:54:18 <dom> Dom: when should we re-evaluate this?
15:54:44 <dom> anssi: the issue doesn't seem very high priority from the Chromium perspective (P3)
15:56:00 <dom> Dom: maybe check back in a month or two and re-evaluate then?
15:56:08 <dom> FJH: I'd say 2 or 3 months
15:56:25 <dom> Topic: Vibration
15:56:36 <dom> s/Battery & Vibration/Battery
15:56:44 <dom> Anssi: no particular update, just editorial work
15:57:05 <dom> Topic: AOB
15:57:18 <dom> [adjourn]
15:57:31 <fjh> Thanks everyone
15:57:34 <dom> RRSAgent, draft minutes
15:57:34 <RRSAgent> I have made the request to generate http://www.w3.org/2017/01/26-dap-minutes.html dom
15:58:19 <fjh> Topic: Adjourn
15:58:27 <fjh> s/AOB/Other Business/
15:59:23 <fjh> Present+ Lukasz_Olejnik
15:59:44 <fjh> Present+ Mikhail_Pozdnyakov
15:59:50 <fjh> rrsagent, generate minutes
15:59:50 <RRSAgent> I have made the request to generate http://www.w3.org/2017/01/26-dap-minutes.html fjh
16:00:14 <fjh> s/FJH/fjh/g
16:00:59 <fjh> s/[adjourn]//
16:01:04 <fjh> rrsagent, generate minutes
16:01:04 <RRSAgent> I have made the request to generate http://www.w3.org/2017/01/26-dap-minutes.html fjh
17:56:59 <zkis> zkis has joined #dap
18:06:50 <Zakim> Zakim has left #dap
18:09:38 <Andrey_Logvinov> Andrey_Logvinov has joined #dap
18:49:42 <Andrey_Logvinov> Andrey_Logvinov has joined #dap
19:39:58 <zkis> zkis has joined #dap
20:58:53 <Andrey_Logvinov> Andrey_Logvinov has joined #dap
22:23:59 <zkis> zkis has joined #dap