14:44:41 RRSAgent has joined #dap 14:44:41 logging to http://www.w3.org/2017/02/09-dap-irc 14:44:43 RRSAgent, make logs world 14:44:43 Zakim has joined #dap 14:44:45 Zakim, this will be DAP 14:44:45 ok, trackbot 14:44:46 Meeting: Device and Sensors Working Group Teleconference 14:44:46 Date: 09 February 2017 14:53:36 Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/0000.html 14:53:53 fjh has changed the topic to: agenda https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/0000.html 14:54:15 Chair: Frederick_Hirsch 14:54:54 Present+ Frederick_Hirsch 14:55:14 dom has joined #dap 14:55:51 Present+ Dominique_Hazael-Massieux 14:56:13 Andrey_Logvinov has joined #dap 14:58:18 Topic: Welcome, scribe selection, agenda review, announcements 15:00:42 Present+ Andrey_Logvinov 15:01:11 Present+ Tobie_Langel 15:01:57 ScribeNick: dom 15:01:59 Present+ Wanming_Lin 15:02:10 Topic: Minutes approval 15:02:20 Approve minutes from 26 January 2017 15:02:20 https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0012/minutes-2017-01-26.html 15:02:21 proposed RESOLUTION: Minutes from 26 January 2017 are approved 15:02:25 RESOLUTION: Minutes from 26 January 2017 are approved https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0012/minutes-2017-01-26.html 15:02:33 Topic: Wake Lock API 15:02:40 close ACTION-784 15:02:40 Closed ACTION-784. 15:03:03 Frederick: we've received new input from the TAG on the updated Wake Lock 15:03:13 Use cases could be improved to include system lock use cases and comment on the RioRun scenario (eg describe scenarios in which developers might be tempted to use a wakelock but should not) 15:03:14 We'd like the security and privacy implications to acknowledge the information leakage risk if wakelocks are denied when battery level is low. You might want to say you're happy with that leakage but it's worth acknowledging it. 15:03:15 Specify how wakelocks interact with the user manually activating the hardware lock mechanism of the device 15:03:28 https://github.com/w3ctag/spec-reviews/issues/126 15:03:44 Frederick: Andrey already replied to one of the comments 15:03:55 ... any thoughts about the other comments? 15:04:24 Andrey: only received feedback very recently; useful feedback on the privacy section 15:04:38 ... re manual lock, seems reasonable too 15:05:02 ... will work on integrating those - no specific help needed at this point 15:05:30 anssik_ has joined #dap 15:05:38 Frederick: we seem to be getting there, thanks Andrey for your continued work on this! 15:05:40 Present+ Anssi_Kostiainen 15:05:49 Andrey: will fix the privacy/security section in the upcoming week 15:06:07 Topic: Generic Sensor API 15:06:22 Frederick: anything that needs discussion on this? 15:06:44 Tobie: I set up a meeting with the folks of the company that had sent feedback and of which we talked about last time 15:07:09 ... with a proposed addition of "bring your own buffer" API, probably only for motion sensors 15:07:21 ... the best path forward is to combine all the mention sensors in a single spec 15:07:32 ... subclass the generic sensor API with a MotionSensor interface 15:07:33 q+ to ask about buffer overflow security concern 15:07:41 ... that all the motion sensors would inherit from 15:07:53 ... which would allow us to move the Generic Sensor stuff faster 15:08:14 ... and focus on the MotionSensor separately, and as it matures, what might migrate back to Generic Sensor over time 15:08:20 q? 15:08:22 s/what/determine what/ 15:08:25 ack fjh 15:08:25 fjh, you wanted to ask about buffer overflow security concern 15:08:42 Frederick: does this create any buffer overflow risk? 15:09:03 Tobie: I haven't thought about this, but I don't see how that would be a concern at our layer in the platform, but I could be wrong 15:10:16 ... Ambient Light & Proximity are very different from the Motion Sensors 15:12:02 Anssi: re Motion Sensors spec - would DeviceOrientation as fusion of Magnetometer be part of this? 15:12:08 ... both low level and fusion sensors 15:12:10 Tobie: absolutely 15:12:40 ... the point is to have the stuff in the same place to reduce boilerplate, but also use it as an opportunity to better explain the platform to developers 15:13:30 ... also might help avoid having implementors implement only a subset of the motion sensors 15:13:37 Mikhail: a couple of questions 15:13:54 ... would it mean that there would be some common APIs uniting all the motion sensors together? 15:14:23 Tobie: to move forward more quickly, I'd like to avoid the trouble we've had with the different reporting mode 15:14:31 ... a MotionSensor subclass would be very useful 15:14:51 ... re high-level vs low-level motion sensors, whether they should inherit from the same subclass, I'm not sure yet 15:15:03 ... will be able to know once I dig into it 15:15:20 Mikhail: some platforms have different reporting modes among motion sensors, so that's a potential concern 15:15:39 tobie: OK, so we will have to deal with this; but at least we'll know what outcome we want, and it will scope down the conversation some what 15:15:48 ... (I hope!) 15:16:27 Mikhail: the dedicated motion sensor spec - any thought about how the common interface will differ from the Generic Sensor API? 15:16:38 Tobie: not at this time; it would inherit from Generic Sensor 15:16:51 ... it might be that the "bring your own buffer" thing is specific to motion sensor 15:17:00 ... can't imagine it be useful e.g. for geolocation 15:17:18 Mikhail: so a more sophisticated API for buffering 15:17:36 tobie: exactly; we might backport it to generic sensor later if we find that's more broadly useful 15:17:48 ... it will help with moving forward with the work 15:18:02 Frederick: can you send a note to the list with your plans? 15:18:07 Tobie: I can do that 15:18:15 Gyroscope pull request to sync up with Generic Sensor API 15:18:43 Topic: HTML Media Capture 15:18:53 VideoFacingModeEnum as the capture attribute's value 15:18:54 https://github.com/w3c/html-media-capture/issues/4 15:19:08 Frederick: there has been a suggestion to add the VideoFacingModeEnum to our capture attribute 15:19:24 Anssi: it was initially in upstream HTML 15:19:56 ... the idea is to provide more finegrained hint - right now it's a boolean to switch from file picker to camera 15:20:10 ... this would allow to pick a specific camera 15:20:21 q+ to ask about how it applies to mic 15:20:42 ... I've been awaiting implementors interest before proceeding 15:21:17 dom: how would it apply to audio picker? 15:21:18 dom: can be used for audio, video, still images, so not sure how this would work for audio or other media types 15:22:07 anssi: it would only work with some media types 15:22:16 dom: enum might issue if want to select a specific microphone 15:22:31 dom: might be ok if the enum only applies to video; not sure if there is a need to pick a specific microphone for this API 15:22:40 upstream issue: https://github.com/whatwg/html/issues/1102 15:22:54 frederick: so overall low priority, waiting for signs of interest 15:23:07 Topic: AOB 15:23:26 Anssi: I closed a bunch of issues that had been settled (as seen in the weekly digest) 15:23:32 http://www.w3.org/mid/E1cb97g-0007oQ-Un@uranus.w3.org 15:23:48 ... from a sensor perspective, only ALS needs to be rebased to updated Generic Sensor 15:26:47 Present+ Mikhail_Pozdnyakov 15:27:24 Topic: Naming in Generic Sensors 15:27:38 ScribeNick fjh 15:27:58 Tobie: on naming - since we moved the connection to the underlying sensor to the sensor instance, we needed a new state 15:28:15 ... the object is initially not connected to a sensors (which is different from not listening) 15:28:32 ... we had a bunch of conversations on the state machine and ended up with being happy with "activation" as a concept 15:28:49 ... first "unactivated", then "activating", "activated", "deactivated", "errored" 15:29:07 ... would everyone be happy with moving to that scheme? 15:30:28 s;ScribeNick fjh;; 15:30:29 ScribeNick fjh 15:30:31 https://github.com/w3c/sensors/issues/160 15:30:49 https://github.com/w3c/sensors/issues/160#issuecomment-275716147 15:31:03 tobie: created diagram 15:31:12 … inconsistent naming 15:32:02 … should we rename start stop method to match activate approach, which seems to have support 15:32:14 … looking for input from Rick 15:32:34 … so we match what Javascript developers like 15:33:09 … so may delay this decision since he is on leave now, but please comment on the issue if you have opinionbs 15:33:20 s/opinionbs/opinions/ 15:33:38 … would like consistency in state names, and short method names, not sure that this is too important 15:34:25 Mikhail: connected sounds like physical, so a bit confusing, so happier with activated, not misleading 15:35:05 Thanks 15:36:56 Topic: Other Business 15:37:19 tobie: added to wakelock TAG issue list, agree with Andrey, not wakelock issue but generic sensor API 15:37:50 Topic: Adjourn 15:37:55 rrsagent, generate minutes 15:37:55 I have made the request to generate http://www.w3.org/2017/02/09-dap-minutes.html fjh 15:38:59 s/Gyroscope pull request to sync up with Generic Sensor API/Gyroscope pull request to sync up with Generic Sensor API completed update/ 15:39:22 s/Frederick/fjh/g 15:39:27 s/frederick/fjh/g 15:44:22 s/not wakelock issue but generic sensor API/not wakelock issue but future (level 2-3? )generic sensor API/ 17:45:28 Zakim has left #dap