See also: IRC log
<trackbot> Date: 07 August 2014
<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/
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 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
anssi: assume you are aligning the implementation with W3C
LisaDeLuca_IBM: updated javascript bridge so shoud affect all across platform
... should be good for all releases should go into Cordova 3.6, next month
... which should we tackle next
fjh: also welcome feedback on battery (later in today's agenda)
... 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
http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0052.html
some vibration tests are still 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
<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
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
LisaDeLuca_IBM: we have some concern about battery, here is link
LisaDeLuca_IBM: 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."
LisaDeLuca_IBM: 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
LisaDeLuca_IBM: yes, will ask
fjh: this is the only remaining Cordova issue/feedback, correct?
LisaDeLuca_IBM: yes
fjh: will raise issue on this one to track it
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
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-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.
fjh: think you might want to consider HTML Media Capture or Light Events, since stable and moving forward
LisaDeLuca_IBM: HTML Media Capture would make sense, stable, don't have anything for Light
<anssik_> http://plugins.cordova.io/#/package/org.awokenwell.proximity
anssik: might be different than plugins
... might be a challenge
LisaDeLuca_IBM: 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
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