W3C

- DRAFT -

Device APIs Working Group Teleconference

07 Aug 2014

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, Cathy, Cathy_Chan, Frederick_Hirsch, Giri_Mandyam, Lisa_DeLuca, Mats_Wichmann, anssik_, fjh, gmandyam, mats
Regrets
Chair
Frederick_Hirsch
Scribe
fjh

Contents


<trackbot> Date: 07 August 2014

Welcome, agenda review, scribe selection, announcements

<scribe> ScribeNick: fjh

Media Capture TF update on list (2 July): http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0017.html

TPAC (27-31 Oct, Santa Clara) Registration now open, http://www.w3.org/2014/11/TPAC/

Minutes approval

Approve minutes from 26 June 2014

http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/att-0116/minutes-2014-06-26.html

RESOLUTION: Minutes from 26 June 2014 are approved

Last Call conclusion and CR publication of HTML Media Capture, Light, Vibration

Last Call drafts of HTML Media Capture, Light, Vibration published, LC ended 24 July 2014

No last call comments on HTML Media Capture.

No last call comments on Light Events.

One Last Call Comment on Vibration API, see https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-vibration-20140619/2945

Proposed resolution: http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0000.html

Proposed RESOLUTION: Adopt proposed resolution for LC-2945, http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0000.html

RESOLUTION: Adopt proposed resolution for LC-2945, http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0000.html

<scribe> ACTION: anssik to add resolution to LC-2945 to draft [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action01]

<trackbot> Created ACTION-706 - Add resolution to lc-2945 to draft [on Anssi Kostiainen - due 2014-08-14].

anssik: should it be a note

fjh: normative is better
... here is response from Microsoft re Lisa comment http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0011.html

anssi: assume you aligning implementation with W3C

lisa: updated javascript bridge so shoud affect all across platform

… should be good for all releases should go into Cordova 3.6, next month

s/releases/releases/

lisa: which should we tackle next

<LisaDeLuca_IBM> http://apache.markmail.org/search/?q=org.apache.incubator.callback-dev+list%3Aorg.apache.incubator.callback-dev+order%3Adate-backward+w3c#query:org.apache.incubator.callback-dev%20list%3Aorg.apache.incubator.callback-dev%20order%3Adate-backward%20w3c+page:1+mid:3qrirxhvzumzkyh2+state:results

fjh: think you might want to consider HTML Media Capture or Light Events, since stable and moving forward

lisa: HTML Media Capture would make sense, don’t have anything for Light

fjh: right, and we of course welcome feedback on battery

lisa: we have some concern about battery, here is link

<anssik_> http://plugins.cordova.io/#/package/org.awokenwell.proximity

fjh: Plan and changes for CR publications: http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0001.html

RESOLUTION: Start 2 week CfC ending 21 August to publish CR drafts of HTML Media Capture, Ambient Light Events, and the Vibration API on 28 August, with details as noted in http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0001.html

<scribe> ACTION: fjh to send CfC for CR for HTML Media Capture, Ambient Light Events, Vibration API [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action02]

<trackbot> Created ACTION-707 - Send cfc for cr for html media capture, ambient light events, vibration api [on Frederick Hirsch - due 2014-08-14].

fjh: suggest we stay with old process for now

http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0012.html

Vibration Test updates

http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0052.html

some vibration tests are stil missing

http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0054.html

anssik: I think we agreed he can write tests even though test facilitator as long as we get review, so I can ask him to write tests for those that are missing

fjh: yes, that is right
... please ask him to do this

anssik: only three missing, one no longer relevant
... I can review the tests
... anssik to ask zhiqiang to complete vibration tests

<scribe> ACTION: anssik to ask zhiqiang to complete vibration tests [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action03]

<trackbot> Created ACTION-708 - to ask zhiqiang to complete vibration tests [on Anssi Kostiainen - due 2014-08-14].

anssik: firefox bug fixed as part of this test

fjh: yes, that was good http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0052.html

Charter Update

fjh: I think we need Dom for this discussion

proposed Wake Lock addition: http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0055.html

WebIntents, http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0023.html (Paul Kinlan)

fjh: not sure what we can do now on this call, please review

anssik: webintents removed from WebApps charter in latest update
... what does this mean with respect to the Task Force

fjh: if it is not in the WebApps charter then I do not believe it makes sense to continue a joint task force, since there could be associated IPR obligations
... that said, I think we can keep the Task Force list and have a Task force for the DAP WG if useful
... we should involve Dom in discussions, he understands bigger chartering picture
... across the groups
... we already have WebIntents work in the DAP charter, given the interest probably makes sense to keep, maybe with some modifications
... presumable we will review a draft charter before formally progressing to recharter
... lets defer discussion until we have Dom on the call with more facts

Battery - Cordova Feedback

<LisaDeLuca_IBM> http://apache.markmail.org/search/?q=org.apache.incubator.callback-dev+list%3Aorg.apache.incubator.callback-dev+order%3Adate-backward+w3c#query:org.apache.incubator.callback-dev%20list%3Aorg.apache.incubator.callback-dev%20order%3Adate-backward%20w3c+page:1+mid:3qrirxhvzumzkyh2+state:results

lisa: we have some concern about battery, here is link

“The spec is flawed in that there's no way we could implement it as it

stands. The spec needs to be reworked to be more event driven and

asynchronous. Right now it's too much like device with everything up

front."

lisa: will follow up

fjh: a concrete proposal would be helpful

anssi: not sure what this means to be “more event driven"
... we already have events in the spec
... too high level comment, need concrete feedback

lisa: yes, will ask

fjh: this is the only remaining Cordova issue/feedback, correct?

lisa: yes

fjh: will raise issue on this one to track it

Open Battery Issues

review issues and status noted in http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0006.html

ISSUE-164?

<trackbot> ISSUE-164 -- Correct default for charging time if unknown in battery -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/164

fjh: can we close

anssik: ok

cathy: ok

close ISSUE-164

<trackbot> Closed ISSUE-164.

ISSUE-165?

<trackbot> ISSUE-165 -- Clarify language around multiple batteries -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/165

fjh: can we close

anssik: yes

cathy: yes

close ISSUE-165

<trackbot> Closed ISSUE-165.

ISSUE-166?

<trackbot> ISSUE-166 -- Should getBattery() always return the same promise? -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/166

mounir’s answer http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0006.html

fjh: we are treating as one virtual battery, so why would you ever have more than one battery manager?
... this should stay open, no resolution

anssik: spec has not been updated
... I will check and respond to mounir on the list
... to follow upon on ISSUE-166 and http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0003.html

<scribe> ACTION: anssik to follow upon on ISSUE-166 and http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0003.html [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action04]

<trackbot> Created ACTION-709 - Follow upon on issue-166 and http://lists.w3.org/archives/public/public-device-apis/2014jul/0003.html [on Anssi Kostiainen - due 2014-08-14].

fjh: we need a concrete proposal so we can be clear on what we agree to. One Promise, one BatteryManager?

anssik: no argument that BatteryManager should be same instance

fjh: why does it matter whether promise is same or not?

anssi: comparision?
... this may be a minor issue

fjh: need to resolve it

ISSUE-167?

<trackbot> ISSUE-167 -- Should Promises be used in Battery API -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/167

fjh: we were accomodating the feedback to use promises uniformly, but maybe that was a mistake

anssik: need opportunity to prompt user before getting battery - advantage of promises
... but slight advantage of having data avaialble syncnronouslly
... first access to battery manager slower than subsequent times

<anssik> https://twitter.com/ebidel/status/494963550683533312

fjh: I thought advantage was usability for code writing, given potential complexity of nested call backs

anssik: true but not used that way in this API so not relevant, since only giving battery manager handler instance, not for the events
... not used here as they are primarily designed
... google concern is performance

fjh: what about web components?

<anssik> https://gist.github.com/ebidel/d9c591d77b4c2b68c347

anssi: have an implementation for old implementation and for the new

fjh: do we have measurements for the old implementation?

<anssik> https://gist.github.com/rwaldron/850590359d298e35bc61

fjh: look there is long startup time on old design as well as new for desktop
... something like object instantiation
... not sure it makes sense for us to analyzie in real time

anssik: should we publish

fjh: think we need to look at some of the bigger issues first

ISSUE-168?

<trackbot> ISSUE-168 -- getBattery() vs. requestBattery() pattern -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/168

anssik: I can summarize issues on the list

fjh: first api was simpler so why not use that? what is the real problem at issue?

anssik: multiprocess but we’ve heard both ways
... will send summary to list of technical issues and key points

<anssik> I can try to summarize on the list what I gather as pros and cons for both the designs

fjh: will suggest going back to original design, ask why not, simplest

anssik: issue of dealing with conflicting implementations, google shipping behind run time flag in canary

fjh: ok so lets take this to the list

http://www.w3.org/2009/dap/track/issues/168

fjh: anssi, I think you need to look at this offline and talk to mounir

<scribe> ACTION: anssik to look at ISSUE-168 http://www.w3.org/2009/dap/track/issues/168 [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action05]

<trackbot> Created ACTION-710 - Look at issue-168 http://www.w3.org/2009/dap/track/issues/168 [on Anssi Kostiainen - due 2014-08-14].

Action Review

ACTION-704?

<trackbot> ACTION-704 -- Lisa Seacat DeLuca to Follow up re closing january cordova feedback -- due 2014-07-03 -- OPEN

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

close ACTION-704

<trackbot> Closed ACTION-704.

ACTION-705?

<trackbot> ACTION-705 -- Anssi Kostiainen to Add warning to Battery API that (naive) implementation of API could negatively affect battery life -- due 2014-08-11 -- OPEN

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

fjh: can defer, will leave open for now, will probably be resolved with other fixes

close ACTION-700

<trackbot> Closed ACTION-700.

close ACTION-702

<trackbot> Closed ACTION-702.

Cordova next steps

lisa: HTML Media Capture makes sense, even if it is stable

anssik: might be different than plugins
... might be a challenge

lisa: can look at it, will send a message to the list about any difficulties

fjh: good to get an idea, can then decide what to do next

Other Business

fjh: Anssik can you please talk to mounir, let’s see if we can understand the core issues, get concrete proposals for battery
... what can we simplify
... next call scheduled for 21 August expect we will discuss the charter if Dom is back

Adjourn

s;s/releases/*;;

Summary of Action Items

[NEW] ACTION: anssik to ask zhiqiang to complete vibration tests [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action03]
[NEW] ACTION: anssik to add resolution to LC-2945 to draft [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action01]
[NEW] ACTION: anssik to follow upon on ISSUE-166 and http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0003.html [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action04]
[NEW] ACTION: anssik to look at ISSUE-168 http://www.w3.org/2009/dap/track/issues/168 [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action05]
[NEW] ACTION: fjh to send CfC for CR for HTML Media Capture, Ambient Light Events, Vibration API [recorded in http://www.w3.org/2014/08/07-dap-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/08/07 16:10:28 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/releases/realeases/
Succeeded: s/anssik/fjh/
Succeeded: s/mounir, if you are lurking on the IRC feel free to participate in the discussion//
Succeeded: s/realeases/releases/
Succeeded: s/all realeases/all releases/
Succeeded: s/close ISSUE=165//
Found ScribeNick: fjh
Inferring Scribes: fjh
Default Present: Lisa_DeLuca, mats, fjh, gmandyam, anssik_, Cathy
Present: Anssi_Kostiainen Cathy Cathy_Chan Frederick_Hirsch Giri_Mandyam Lisa_DeLuca Mats_Wichmann anssik_ fjh gmandyam mats
Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0007.html
Found Date: 07 Aug 2014
Guessing minutes URL: http://www.w3.org/2014/08/07-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]