See also: IRC log
<lukasz> hey
<tobie> https://github.com/w3c/sensors/issues/75
<tobie> https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md
should devloper 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
<scribe> ScribeNick: fjh
UNKNOWN_SPEAKER: dumb sensors are
polled
... smart sensors push
fjh: polling with very short time becomes streaming
tobie: usually push is enough,
can easilty replicate as if polled
... doesn’t work for low level access need continous 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 implemenation 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
s/.*dumb sensors/tobie: dumb sensors/
fjh: next steps?
tobie: have propsed 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 lanugage, workgin on
... just talked about 75
... 66, need to document properl;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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/possilbe/possible/ Succeeded: s/Sensors/Generic Sensor API/ Succeeded: s/provides/Qualcomm provides/ Succeeded: s/phne/phone/ FAILED: s/.*dumb sensors/tobie: dumb sensors/ Succeeded: s/me anssi guess we will cancel since only tobie and I are on the call// Succeeded: s/anssi perhaps you can follow up on email re battery and vibration// Succeeded: i/hey/Topic: Welcome , Agenda Review, Scribe Selection Found ScribeNick: fjh Inferring Scribes: fjh Present: Frederick_Hirsch Tobie_Langel Anssi_Kostiainen Regrets: Andrey_Logvinov Dominique_Hazael-Massieux Giri_Mandyam Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Feb/0017.html Found Date: 04 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/04-dap-minutes.html People with action items: anssik fjh WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]