See also: IRC log
<scribe> ScribeNick: dom
<fjh> The WG Note marking the shelving of Network Service Discovery has been published: https://www.w3.org/TR/2017/NOTE-discovery-api-20170112/
<fjh> Now have weekly digest of GitHub activity (thanks Dom)
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0007.html
<fjh> reminder public-device-apis-log mail list is very useful
https://lists.w3.org/Archives/Public/public-device-apis-log/
<fjh> Approve minutes from 12 January 2017
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0004/minutes-2017-01-12.html
<fjh> proposed RESOLUTION: Minutes from 12 January 2017 are approved
RESOLUTION: Jan 12 2017 minutes approved https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/att-0004/minutes-2017-01-12.html
fjh: lots of issues closed on generic sensor, great progress
... could you summarize the status?
Tobie: I've been catching up on a lot of the conversations we've had in the couple of weeks
... assessing input and learning from implementations
... and figuring out the best route forward
... I rewrote a big bunch of the spec, closing a bunch of issues
... 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
... in the process of doing that, and thanks to Alex and Mikhail's input
... I identified a number of open questions / issues which I've put in-line in the spec
... will maybe move them to github, but not sure that's the best option yet
... this leaves us with:
... * a number of areas in the spec that need editorial work (cleanup, better examples, etc)
... * 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
... what I've learned from the Chromium implementation is an interesting strategy to coupling it with requestAnimationFrame
... 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
... with e.g. the possibility in a later version of the spec to buffer readings prior to delivery
... I need to check that this actually solves the use cases that we were providing with
... and see with implementors if that strategy makes sense and if it is applicable across platforms
... it helps answer questions also around periodic reporting mode
... and be more precise about how we spec the tiny details of how this actually work
... that's for the high level stuff
<anssik> Level 1 open issues now down to 9: https://github.com/w3c/sensors/milestone/2
Tobie: I also did a lots of small changes to the spec to address some of the security / privacy issues
... but there still needs to be clean up
fjh: what's the outcome on garbage collection? what about permissions?
Tobie: good questions
... I need to open an issue around "bring your own buffer"
... with regard to permissions, Anssi noted that we're kind of out of sync with the permission spec
... I have a bunch of concerns around permissions
... mainly that the spec isn't moving very fast nor answering a bunch of questions we have to answer
... and it's not at the top of the priority list of its lead editor Jeffrey
... the spec is at a stage where it's good enough for them
... it sort of works for us but not in the best possible way
... I'm also waiting for feedback from the Chromium security team
... which will provide valuable feedback esp from the UI implementation perspective
... With regard to garbage collection, the big revamp of the spec fixes this -
... one missing piece is for values that need to be passed by reference, have a "bring-your-own-buffer" mechanism
... which I want to align with other specs that have similar needs
... I think we have that need e.g. for motion sensors with matrices/quaternions
fjh: it might be useful to make an explicit note on GC design in the spec
Tobie: good point
fjh: what about the TAG?
Tobie: The TAG had reviewed and sent a bunch of comments on the spec
... we should probably ping them once the spec stabilizes again
... 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
... I would like that in before getting the TAG to review it again
... also, I'm much more confident in writing this more precisely with my WebIDL editor experience
https://tabatkins.github.io/bikeshed/#cli-echidna
fjh: should we publish an updated WD?
Tobie: probably
Dom: +1 ; publish early & often
<fjh> +1
Dom: see https://tabatkins.github.io/bikeshed/#cli-echidna in how to publish with bikeshed
Anssi: [blasting standardization pace]
<fjh> well now Anssi is back, so the progress will speed up
<anssik> +1 to publish an updated WD as soon as possible
<fjh> publish updated WD now
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
... the distinction between capturing data at a given frequency vs reading that data from JS
... is a nice way to think about this problem space
... the work is now to put that into spec form
Dom: what's our timeline for new TAG review and then possibly CR transition?
Tobie: it will depends on the feedback on permission/security from Chrome team
... and input from implementors on the overall design
... and feedback on high level frequency
Dom: another way to look at this is what's the plans from implementors?
Anssi: next step for Chromium will be origin-trials - no committed timeline at the moment
... also, we need to synchronize the spec with implementation
<fjh> note origin trials means only white listed sites can use the API
Mikhail: there are still pretty gaps with the onchange behavior
... I also noticed the new state called "unconnected"
tobie: yes, I had to add this - there was implementation feedback that the default sensor could not be figured out synchronously
... the object needed a special state
... if there are better ideas of a name, I'd be interested
Mikhail: undefined?
... I've also more questions on the state machine - this state can never be reached again?
Tobie: I'm not super attached to the current state machine if there are reasons to do that
Mikhail: if you call start, and there is no sensor what's the next state?
Tobie: it should be "errored"
... first state is not connected to hardware, then connecting, then connected
... if at any point there is a fatal error, you move to errored
... otherwise, if you stop it, you move to idle
... (connected but not polling)
<anssik> Gyro adapted https://github.com/w3c/gyroscope/pull/10
Anssi: Mikhail started adapting the gyro API to the updated generic sensor
Mikhail: I moved the reading to the sensor interface itself
Anssi: tobie, will you be adapting Ambient Light to the new Generic Sensor?
Tobie: good idea
... I can also look at the Gyro pull request to make sure it's aligned
Anssi: from what I understand from Mikhail, the adaption was fairly straightforward
Mikhail: the procedure for reading in Generic Sensor is using internally a Map - what does it mean in practice?
<anssik> https://infra.spec.whatwg.org/#ordered-map
Tobie: I think that this matches the buffer you have in the implementation
... it's probably one single map per sensor per origin
... that just stores the data that is read from the sensor itself
... and it is updated at every requestAnimationFrame
... and all the concrete sensor instances just get the value from it
... it's an abstract object
... I'm relying on the Infra spec
... it's an abstract data structure that all the instances tap into
... probably need to do a diagram of how this all works
<fjh> Mikhail: will open some other detailed issues
Tobie: 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
<fjh> tobie: or make pull requests
fjh: Dom was to ping that TAG to get an updated review
... and maybe discuss some of the respec issues
Dom: pinged them, not heard back yet
fjh: Anssi, is there a way you could help Andrey with the new warnings from respec?
<anssik> https://github.com/w3c/respec/wiki/data-dfn-for
<anssik> see also https://github.com/w3c/respec/wiki/WebIDL-Guide
Anssi: the pointer above explains the issue
... ReSpec is more agressive in requiring prose for each and every WebIDL item
Dom: feel free to ping me Andrey if you're still not finding your way
<fjh> moving forward with implementation would be useful to learn, depends on if TAG feedback would result in rework
Andrey: does it make sense for me to move with implementation? or should we wait for feedback?
Dom: implementation experience would be helpful for the spec
... but it depends on how much implementation efforts you can afford without certainty
<fjh> suggest we get a slot on the TAG agenda for Wake Lock
<fjh> best way to get attention
fjh: would be good if this could move up earlier rather than later on the TAG agenda
<fjh> ACTION: fjh to ask TAG to put Wake Lock on agenda [recorded in http://www.w3.org/2017/01/26-dap-minutes.html#action01]
<trackbot> Created ACTION-784 - Ask tag to put wake lock on agenda [on Frederick Hirsch - due 2017-02-02].
Dom: not sure how to do that - maybe ask nicely from chair to chairs? >:)
<Andrey_Logvinov> https://github.com/w3ctag/spec-reviews/issues/126#issuecomment-257137369
fjh: Battery - we're waiting for more implementation - but how long should we wait?
Anssi: the current status is that Mozilla unshipped it, but Chrome and other derivative browsers are shipping it
<anssik> http://caniuse.com/#search=battery
<anssik> expand with show all
Anssi: Chrome, Opera, Opera Mobile, Android Browser, Chrome Mobile, UC, Samsung Internet ships it
... given the mobile focus, Firefox dropping it is not having much impact from a market share perspective
<anssik> https://crbug.com/661792
Anssi: For Chromium, there is an open issue opened by lukasz
... which has been assigned to Tim Volodine
... latest update in December
... as a result, I think it's still a bit premature to make a decision
... there may be integration with permission API as the result, which may allow Firefox to ship it again
<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
<fjh> dom: another view is that more work brings Firefox back
<fjh> dom: agree, don’t need to make assessment now, but probably need to think through our approach
<anssik> https://developer.microsoft.com/en-us/microsoft-edge/platform/status/batterystatusapi/
Anssi: Edge has it "under consideration"
Dom: when should we re-evaluate this?
anssi: the issue doesn't seem very high priority from the Chromium perspective (P3)
Dom: maybe check back in a month or two and re-evaluate then?
fjh: I'd say 2 or 3 months
Anssi: no particular update, just editorial work
<fjh> Thanks everyone