See also: IRC log
<scribe> ScribeNick: fjh
<tobie> https://github.com/w3c/sensors/issues/75
<tobie> https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md
should developer care about streaming vs polling type of sensor or should they look the same
on change vs continuous
fjh: should care if interested in data
tobie: depends on use case, e.g for map positioning might not matter
... for geolocation doesn’t matter
... dumb sensors are polled
... smart sensors push
fjh: polling with very short time becomes streaming
tobie: usually push is enough, can easily replicate as if polled
... doesn’t work for low level access need continuous stream, e.g. virtual reality
fjh: auto?
giri: everything is interrupt driven on handsets
... streaming or poll choice irrelevant in this case, depends on underlying implementation
fjh: consistent API possible
giri: different drivers by manufacturer, intellectual property, so not uniform
tobie: hardware abstraction layer makes this less important
giri: still need to consider what is underneath, e.g Android HAL has not kept up, e.g. depth cameras
tobie: depth camera is not in our scope
giri: developers need to be aware of limitations
... with respect to frequency returned by sensor
tobie: need to understand real developer use cases
... removed everything from spec that IOS and Android could not provide
giri: can you tell me what implementation needs to provide, so I can check if it is possible
tobie: have checked IOS and Android
giri: Qualcomm provides DSP for both IOS and Android
tobie: geolocation is easier across platforms
... gyroscope etc are typically polled
... clear cut across platform
... not so clear - heart rate, ambient light, etc not clear whether to poll or stream
... more research required
giri: some of these are not integrated into smart phone
tobie: implementer does not know
giri: are these sensors dynamically discoverable
tobie: saving for L2 of spec
... remaining questions - how to present two options to developer in compelling way
giri: non-trivial question
fjh: next steps?
tobie: have proposed set of sensor types, underlying physical sensors, see table
https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md
tobie: need reporting mode - on data change or continuous
... if same on Android and IOS can go with that
... checking if we can get same output on both
... look at outstanding issues
<tobie> https://github.com/w3c/sensors/milestones/Level%201
tobie: answered #81, anssik added text
... 79 imposed by platform
fjh: can you add proposed resolution for 79 and for 81
tobie: yes
... need to improve language, working on
... just talked about 75
... 66, need to document properly;y
... 62 punt
... remaining ones require edits to spec and can be closed when done
... last blocker is permissions API
... issue 22
https://github.com/w3c/sensors/issues/22
tobie: nice to have, not must
... adding enums into webIDL
... avoid need to avoid modifying permissions API, but may not get support
<tobie> https://lists.w3.org/Archives/Public/public-script-coord/2015AprJun/0061.html
tobie: discussion was on public-script-coords
... could also use DOMString instead of enum
fjh: cannot expect to modify permissions API for every new API
tobie: easier to argue once have generic sensor API
... reason against is not to spread enums across specs, makes it hard
... but want permission tied to implementing the sensor
fjh: suggest putting it into generic sensor API by default with note explaining rationale
... better to have it there rather than starting without it
tobie: yes, good idea
... benefit of DOMString does not require webIDL change
... will do issue cleanup once spec is updated
fjh: for issues not from Tobie we need to be able to show resolutions as we move through the process
<tobie> list of issues not opened by editor: https://github.com/w3c/sensors/issues?utf8=%E2%9C%93&q=+is%3Aissue+-author%3Atobie+
<scribe> ACTION: fjh to discuss with tobie how to generate report showing issues reported by others and how resolved [recorded in http://www.w3.org/2016/02/04-dap-minutes.html#action01]
<trackbot> Created ACTION-743 - Discuss with tobie how to generate report showing issues reported by others and how resolved [on Frederick Hirsch - due 2016-02-11].
Approve minutes from 21 Jan 2016
proposed RESOLUTION: Minutes from 21 Jan 2016 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/att-0062/minutes-2016-01-21.html
RESOLUTION: Minutes from 21 Jan 2016 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/att-0062/minutes-2016-01-21.html
fjh: where are we now, including delays on tests
anssik: spec gives leeway, so some tests are hard, cannot predict time for test to run to completion, so get some failures
... looking at test results, close to complete now
<anssik> https://w3c.github.io/test-results/battery-status/all.html
fjh: this is much better than before
anssik: still have IDL failure related to harness, Dom had patch
... webIDL implementation issues
... total of 4 failures in both of two implementations
fjh: will need Dom’s help
... what is yellow
anssik: manual tests
... tobie do you know what yellow means
tobie: not sure
... but think so
... undefined - means was not run
anssik: does this tool even work with manual tests
fjh: need to clarify what bottom of table means
anssik: yes, can do this. But China new year starts Monday
<scribe> ACTION: anssik to clarify battery test report , removing or explaining yellow at bottom of report [recorded in http://www.w3.org/2016/02/04-dap-minutes.html#action02]
<trackbot> Created ACTION-744 - Clarify battery test report , removing or explaining yellow at bottom of report [on Anssi Kostiainen - due 2016-02-11].
fjh: Clarification errata item, ISSUE-171
... first need proposal for change, then CfC for agreement, then update Errata and do PER
... Focus should be on agreement to change then mechanics to get it done
fjh: remaining issues are here https://github.com/w3c/wake-lock/issues
... looks like these need to be resolved.
... defer discussion
fjh: none