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
... 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
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
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
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
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
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-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.
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
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
s;s/releases/*;;
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]