W3C

- DRAFT -

Device APIs Working Group Teleconference

03 Sep 2015

Agenda

See also: IRC log

Attendees

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

Contents


<trackbot> Date: 03 September 2015

Welcome, scribe selection, agenda review, announcements

<Dapeng_Liu> May I ask what is the meeting password?

<Dapeng_Liu> thanks

<fjh> ScribeNick: fjh

the /TR style sheet response sent: https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0021.html

fjh: I submitted the style sheet response

TPAC reminder (no DAP F2F): http://www.w3.org/2015/10/TPAC/

fjh: who will be leading breakout session at TPAC

anssik: I will be there, expect Tobie as well, Giri you might wish to join

giri: put out call for future information on device orientation, got no response
... Rich left Opera
... should close issue

anssik: will device orientation move

giri: first want LC, but Apple still not compliant so an issue
... need LC first
... this does not stop revising device orientation under the generic sensor API

tobie: have looked over the last two weeks looking at device orientation to get sense for use cases for generic sensor API

<anssik> +1

dom: geolocation WG had no objection to DAP taking over device orientation so we should add to charter

+1

<anssik> +1

Welcome to new members: Dapeng Liu, Rong Zhang (Alibaba), Rijubrata Bhaumik (Intel), Alexandra Mikityuk (Deutsche Telekom), Josh Soref (IE)

Viacom has also joined (no participant)

participants list: http://www.w3.org/2000/09/dbwg/details?group=43696&public=1&order=org

dapeng: from Alibaba group, working in standards group
... interested in all of the work of this group

fjh: do you plan to contribute to implementation and testing

dapeng: no plans yet, but would like to help with testin

anssi: Rijubrata contributing to Chromium, working on browser code, will be implementing some of the sensor APIs

fjh: Proximity and Ambient Light Event API WDs published, with warning that moving toward generic sensor API

https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0002.html

Minutes approval

Approve minutes from 25 June 2015

proposed RESOLUTION: Minutes from 25 June 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/att-0175/minutes-2015-06-25.html

RESOLUTION: Minutes from 25 June 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/att-0175/minutes-2015-06-25.html

Charter revision

https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0149.html

created diff http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2011%2F07%2FDeviceAPICharter&doc2=http%3A%2F%2Fw3c.github.io%2Fdap-charter%2FDeviceAPICharter.html

<anssik> http://w3c.github.io/dap-charter/DeviceAPICharter.html

<dom> https://github.com/w3c/dap-charter/issues

There is also a pull request regarding licensing

https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0003.html

dom: if there are new work items to add, now is a good time to do so
... would like to finailize the charter by the end of this month
... please look at the charter, look at the open issues, consider new items that should be added to the charter

Battery

Draft updated for privacy considerations: https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0011.html

fjh: thanks Anssi for updating draft for privacy consideration

Mozilla update, need for test harness update?

https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0018.html

fjh: test harness does not handle promises

anssi: yes idl harness needs to be updated, sent mail, awaiting response, could work around it

fjh: follow up with James next week?

anssi: they need to figure it out

Generic Sensor Use Cases

<dom> ScribeNick: dom

<tobie> http://w3c.github.io/sensors/usecases.html

tobie: basically, we came to the conclusion a couple of weeks ago that it was hard to get to consensus on the exact API design
... because they were hard to express in WebIDL
... I realized that having code examples based on use cases would help
... the idea of the use cases doc is to document real-world applications related to sensor work
... and also look at building polyfills for existing APIs
... I've worked on two such apps based on GH discussions

<tobie> http://w3c.github.io/sensors/examples/realtime-positioning/index.html

tobie: the first one is real time positioning on a map using geolocation
... it's not completely finished but it already brought me to interesting conclusions on sensor frequency
... one of the keys is to try to minimize the battery consumption
... so you need some indication on how often the sensor should be probed

giri: we have had agreement for device orientation
... built on sensor api
... I don't think there is such an agreement for geolocation
... not sure my company would agree to it
... we can use it as a use case, but I don't want us to commit to move geo to this model

tobie: good point

anssi: there can always be a polyfill in any case
... and it informs our design

fjh: right; but we should make clear that we're not saying geo will move to that model

[an issue will be raised in github to track this]

tobie: there has been a bunch of issues raised on generic sensors based on the experience with the geolocation API
... that's why I started looking at it in more details
... example of issues include accessing cached data

<tobie> http://w3c.github.io/sensors/examples/cached-data/index.html

tobie: the 2nd example is in fact based on this cached data aspect
... combined with looking at the battery level

<fjh> fjh: suggest adding note that says that geolocation is included as use case to better understand generic model but does not imply that standard work will move the Geolocation WG or to imply that the standard will be changed at this time.

fjh: so this document is not just text, it also has working code

tobie: indeed; there are also separate links to each app
... I'm not convinced yet this is the best format for the end document, but it is good way to present this right now
... I then spent a lot of time on devising an app for head tracking based on device orientation api
... it proved to be very complicated
... I found an interesting paper from occulus that might help; will give another go at it next week
... head tracking is one of the most cross-sensors type of app you can do in an app right now

<fjh> side comment - not sure I like privacy invasive technologies, head tracking might be one of those

tobie: also spent time on device orientation
... I'm looking for a couple of extra use cases that touch on other aspects beyond these
... I'm hoping to have something ready to be published as a FPWD for our next call

fjh: some of our existing work on proximity or ambient light could be added

tobie: right; I'm not as familiar with these but I can take a look

dom: so FPWD 2 weeks from now — do you think we would publish it with or without the live apps?

tobie: I don't know; I think it's cool to have them in, but have no strong opinions

<fjh> fjh: if we have them in, there might be issues with the publication process

<fjh> dom: I'll need to look ahead of time to see if we want them in or not

tobie: another approach would be to have screenshots instead of live apps

<fjh> tobie: could replace with screen shots if needed, then link to demo apps on github

anssi: yes, with links to the demo apps
... also, we should add more code snippets to contrast the approaches

tobie: yes, that's the goal: more code, explanations
... I'm happy to replace live apps with screenshots and links

fjh: are we talking about being ready for FPWD two weeks from now?

tobie: yes

anssi: sounds like a plan!

[amazing agreement all over]

Generic Sensor API

Generic Sensor API update

tobie: my goal is to use the use cases to come to agreement as to what works and what doesn't
... that's the main issue right now to move forward
... the output of the use cases work will be direct input to the generic sensor api work
... my current hope is to get to FPWD-ready for the API 4 weeks from now
... that might be optimistic, but I'll use that as a target

Wake lock API

<fjh> status - https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/att-0000/00-part

<fjh> (from https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0000.html)

fjh: not aware of news on that one

Andrey: we updated the spec to move the wake lock request attribute from document to the Screen interface
... the implementation of the wake lock api has landed in Blink
... and the Chromium part is waiting for review

fjh: what should be our next steps?

andrey: we should update the WD to reflect the editors draft

fjh: can we use the simplified publication process?

dom: yes; we could even do that automatically

andrey: that'd be good

<fjh> ACTION: dom to update current WD of Wake Lock and set it up so WD is updated automatically when ED updated [recorded in http://www.w3.org/2015/09/03-dap-minutes.html#action01]

<trackbot> Created ACTION-738 - Update current wd of wake lock and set it up so wd is updated automatically when ed updated [on Dominique Hazaël-Massieux - due 2015-09-10].

dom: ok, I'll look into both publishing an update and set up the automation

<fjh> fjh: how are we notified about updates to WD

dom: I'll look into it

<fjh> dom: home page news should be updated first time

Other Specs

<fjh> no news

Actions

<fjh> ACTION-723: Zhiqiang Zhang to Add test for user denial of captured file leading to no capture

<trackbot> Notes added to ACTION-723 Add test for user denial of captured file leading to no capture.

<fjh> ACTION-727: Anssi Kostiainen to Contact tim and boris re joining dap

<trackbot> Notes added to ACTION-727 Contact tim and boris re joining dap.

<fjh> ACTION-729: Zhiqiang Zhang to Update test case to clarify manual testing and to run tests and update results related to action-723

<trackbot> Notes added to ACTION-729 Update test case to clarify manual testing and to run tests and update results related to action-723.

<fjh> ACTION-730: Zhiqiang Zhang to Update the battery test suite to match latest battery spec (coordinating with marcos)

<trackbot> Notes added to ACTION-730 Update the battery test suite to match latest battery spec (coordinating with marcos).

<fjh> ACTION-731: Dominique Hazael-Massieux to Review html media capture tests

<trackbot> Notes added to ACTION-731 Review html media capture tests.

<fjh> ACTION-732: Anssi Kostiainen to Review html media capture tests

<trackbot> Notes added to ACTION-732 Review html media capture tests.

<fjh> ACTION-733: Giridhar Mandyam to Discuss generic sensor api and use of eventtarget in geolocation wg to summarize issues to dap

<trackbot> Notes added to ACTION-733 Discuss generic sensor api and use of eventtarget in geolocation wg to summarize issues to dap.

<fjh> ACTION-734: Anssi Kostiainen to Contact mozilla and microsoft re interest in implementing html media capture vs shelving

<trackbot> Notes added to ACTION-734 Contact mozilla and microsoft re interest in implementing html media capture vs shelving.

<fjh> ACTION-735: Anssi Kostiainen to Create editor drafts for ambient light and proximity indicating new approach toward generic sensor api, also drafts for publication to tr space

<trackbot> Notes added to ACTION-735 Create editor drafts for ambient light and proximity indicating new approach toward generic sensor api, also drafts for publication to tr space.

<fjh> ACTION-736: Frederick Hirsch to Send cfc for wd publication for ambient light and proximity once drafts available

<trackbot> Notes added to ACTION-736 Send cfc for wd publication for ambient light and proximity once drafts available.

<fjh> completed

<fjh> ACTION-735?

<trackbot> ACTION-735 -- Anssi Kostiainen to Create editor drafts for ambient light and proximity indicating new approach toward generic sensor api, also drafts for publication to tr space -- due 2015-07-02 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/735

<fjh> close ACTION-735

<trackbot> Closed ACTION-735.

<fjh> ACTION-736?

<trackbot> ACTION-736 -- Frederick Hirsch to Send cfc for wd publication for ambient light and proximity once drafts available -- due 2015-07-02 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/736

<fjh> close ACTION-736

<trackbot> Closed ACTION-736.

Adjourn

<fjh> Thanks Tobie for preparing the generic sensor API use cases draft and presenting it, Anssi for the publication and battery work. Thanks Dom for scribing, thanks everyone! good call.

<fjh> s/Topic: Generic Sensor API$//

<fjh> Plan is to have updated Generic Sensor API Use Cases document ready before call in next two weeks, to discuss and then publish FPWD

<fjh> Plan is also to publish updated WD of Wake Lock API and to arrange automatic WD updates when ED updated.

Summary of Action Items

[NEW] ACTION: dom to update current WD of Wake Lock and set it up so WD is updated automatically when ED updated [recorded in http://www.w3.org/2015/09/03-dap-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/09/03 14:55:39 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Dapend/Dapeng/
Succeeded: s/This is me//
Succeeded: s/dialed in via phone//
Succeeded: s/TPA/TPAC/
Succeeded: s/compiant/compliant/
Succeeded: s/+1//
Succeeded: s/warnng/warning/
Succeeded: s/deviceorientation/device orientation/
FAILED: s/Topic: Generic Sensor API$//
Found ScribeNick: fjh
Found ScribeNick: dom
Inferring Scribes: fjh, dom
Scribes: fjh, dom
ScribeNicks: fjh, dom
Present: Andrey_Logvinov Anssi_Kostiainen Dapeng_Liu Dominique_Hazael-Massieux Frederick_Hirsch Giri_Mandyam Tobie_Langel
Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0021.html
Found Date: 03 Sep 2015
Guessing minutes URL: http://www.w3.org/2015/09/03-dap-minutes.html
People with action items: dom

[End of scribe.perl diagnostic output]