See also: IRC log
<fjh> ScribeNick: dom
<fjh> Approve minutes from 26 January 2017
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0012/minutes-2017-01-26.html
<fjh> proposed RESOLUTION: Minutes from 26 January 2017 are approved
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
close ACTION-784
<trackbot> Closed ACTION-784.
Frederick: we've received new input from the TAG on the updated Wake Lock
<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)
<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.
<fjh> Specify how wakelocks interact with the user manually activating the hardware lock mechanism of the device
<fjh> https://github.com/w3ctag/spec-reviews/issues/126
Frederick: Andrey already replied to one of the comments
... any thoughts about the other comments?
Andrey: only received feedback very recently; useful feedback on the privacy section
... re manual lock, seems reasonable too
... will work on integrating those - no specific help needed at this point
Frederick: we seem to be getting there, thanks Andrey for your continued work on this!
Andrey: will fix the privacy/security section in the upcoming week
Frederick: anything that needs discussion on this?
Tobie: I set up a meeting with the folks of the company that had sent feedback and of which we talked about last time
... with a proposed addition of "bring your own buffer" API, probably only for motion sensors
... the best path forward is to combine all the mention sensors in a single spec
... subclass the generic sensor API with a MotionSensor interface
... that all the motion sensors would inherit from
... which would allow us to move the Generic Sensor stuff faster
... and focus on the MotionSensor separately, and as it matures, determine what might migrate back to Generic Sensor over time
<Zakim> fjh, you wanted to ask about buffer overflow security concern
Frederick: does this create any buffer overflow risk?
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
... Ambient Light & Proximity are very different from the Motion Sensors
Anssi: re Motion Sensors spec - would DeviceOrientation as fusion of Magnetometer be part of this?
... both low level and fusion sensors
Tobie: absolutely
... 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
... also might help avoid having implementors implement only a subset of the motion sensors
Mikhail: a couple of questions
... would it mean that there would be some common APIs uniting all the motion sensors together?
Tobie: to move forward more quickly, I'd like to avoid the trouble we've had with the different reporting mode
... a MotionSensor subclass would be very useful
... re high-level vs low-level motion sensors, whether they should inherit from the same subclass, I'm not sure yet
... will be able to know once I dig into it
Mikhail: some platforms have different reporting modes among motion sensors, so that's a potential concern
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
... (I hope!)
Mikhail: the dedicated motion sensor spec - any thought about how the common interface will differ from the Generic Sensor API?
Tobie: not at this time; it would inherit from Generic Sensor
... it might be that the "bring your own buffer" thing is specific to motion sensor
... can't imagine it be useful e.g. for geolocation
Mikhail: so a more sophisticated API for buffering
tobie: exactly; we might backport it to generic sensor later if we find that's more broadly useful
... it will help with moving forward with the work
Frederick: can you send a note to the list with your plans?
Tobie: I can do that
<fjh> Gyroscope pull request to sync up with Generic Sensor API has completed update to align with Generic Sensor API
<fjh> VideoFacingModeEnum as the capture attribute's value
<fjh> https://github.com/w3c/html-media-capture/issues/4
Frederick: there has been a suggestion to add the VideoFacingModeEnum to our capture attribute
Anssi: it was initially in upstream HTML
... the idea is to provide more finegrained hint - right now it's a boolean to switch from file picker to camera
... this would allow to pick a specific camera
... I've been awaiting implementors interest before proceeding
dom: how would it apply to audio picker?
<fjh> dom: can be used for audio, video, still images, so not sure how this would work for audio or other media types
anssi: it would only work with some media types
<fjh> dom: enum might issue if want to select a specific microphone
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
<anssik_> upstream issue: https://github.com/whatwg/html/issues/1102
frederick: so overall low priority, waiting for signs of interest
Tobie: on naming - since we moved the connection to the underlying sensor to the sensor instance, we needed a new state
... the object is initially not connected to a sensors (which is different from not listening)
... we had a bunch of conversations on the state machine and ended up with being happy with "activation" as a concept
... first "unactivated", then "activating", "activated", "deactivated", "errored"
... would everyone be happy with moving to that scheme?
<tobie> https://github.com/w3c/sensors/issues/160
<tobie> https://github.com/w3c/sensors/issues/160#issuecomment-275716147
<fjh> ScribeNick: fjh
tobie: created diagram
... inconsistent naming
... should we rename start stop method to match activate approach, which seems to have support
... looking for input from Rick
... so we match what Javascript developers like
... so may delay this decision since he is on leave now, but please comment on the issue if you have opinions
... would like consistency in state names, and short method names, not sure that this is too important
Mikhail: connected sounds like physical, so a bit confusing, so happier with activated, not misleading
tobie: added to wakelock TAG issue list, agree with Andrey, not wakelock issue but generic sensor API
<scribe> ScribeNick: dom
Anssi: I closed a bunch of issues that had been settled (as seen in the weekly digest)
<anssik_> http://www.w3.org/mid/E1cb97g-0007oQ-Un@uranus.w3.org
Anssi: from a sensor perspective, only ALS needs to be rebased to updated Generic Sensor
<anssik_> Thanks