IRC log of dap on 2017-02-09

Timestamps are in UTC.

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