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