W3C

- DRAFT -

Device APIs Working Group Teleconference

04 Feb 2016

Agenda

See also: IRC log

Attendees

Present
Frederick_Hirsch, Tobie_Langel, Anssi_Kostiainen
Regrets
Andrey_Logvinov, Dominique_Hazael-Massieux, Giri_Mandyam
Chair
Frederick_Hirsch
Scribe
fjh

Contents


<lukasz> hey

<tobie> https://github.com/w3c/sensors/issues/75

<tobie> https://github.com/w3c/sensors/blob/gh-pages/sensor-types.md

Generic Sensor API

Welcome , Agenda Review, Scribe Selection

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].

Minutes approval

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

Battery Status API

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].

Vibration

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

WakeLock

fjh: remaining issues are here https://github.com/w3c/wake-lock/issues
... looks like these need to be resolved.
... defer discussion

Other business

fjh: none

Adjourn

Summary of Action Items

[NEW] 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]
[NEW] 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]
 

Summary of Resolutions

  1. Minutes from 21 Jan 2016 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2016Jan/att-0062/minutes-2016-01-21.html
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/04 16:04:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]