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
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/be // Succeeded: s/connected/unconnected/ Succeeded: s/Michail/Mikhail/ Succeeded: s/Michail/Mikhail/g Succeeded: s/rAF/received animation frame/ Succeeded: s/received animation frame/requestAnimationFrame/ Succeeded: s/ping them/pinged them/ Succeeded: s/Battery & Vibration/Battery/ Succeeded: s/AOB/Other Business/ Succeeded: s/FJH/fjh/g Succeeded: s/[adjourn]// Found ScribeNick: dom Inferring Scribes: dom Present: Frederick_Hirsch Dominique_Hazael-Massieux Andrey_Logvinov Tobie_Langel Anssi_Kostiainen Lukasz_Olejnik Mikhail_Pozdnyakov Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0008.html Found Date: 26 Jan 2017 Guessing minutes URL: http://www.w3.org/2017/01/26-dap-minutes.html People with action items: fjh[End of scribe.perl diagnostic output]