See also: IRC log
<trackbot> Date: 26 June 2014
Approve minutes from 12 June 2014
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/att-0062/minutes-2014-06-12.html
RESOLUTION: Minutes from 12 June 2014 are approved
Last Call drafts of HTML Media Capture, Light, Vibration published, LC ends 24 July 2014
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0076.html
fjh: assuming no comments on the LC drafts we would go to CR after, avoiding moratorium, planning 2nd week of Aug
... thanks Anssi and all re preparing LC
... planning on CR publication 12 or 14th Aug; lets plan on 14 Aug
next steps summary and questions: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0080.html (Frederick)
additional comment http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0081.html (Mounir)
fjh: have proposed changes, Proposed edit to new 2nd paragraph in section 6, http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0077.html
Follow up question/comment from Cathy http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0079.html
fjh: cathy what is the issue here?
anssik: not sure what to change
cathy: mounir said if device is charging but don't know charging time should set to infinity, spec says set to zero
anssik: can you please give a concrete request for changes or show commit
... I plan to do all the edits later at once, so an email would help
fjh: mounir says 'spec says to Infinity if the device is charging, zero if *charged*'
... why does it matter which choice of default, does charging state matter
anssik: knowing you have battery matters
fjh: ok, so like having full battery
... ok, need to be consistent with full battery, thus unknown should be 0
cathy: will send email proposal
gmandyam: old coremob had developer survey, no developers using battery other than those creating battery meters
... maybe get rid of charging time, not accurate, quick charge is an example
... snapdragon gives some capabilities to hardware, do not expose quick charge presence
... discharge time is very innacurate
... maybe we should get rid of both, not trustworhty
anssik: disagree, look at firefox, returns values on all platforms
gmandyam: can return it, but not necessarily correct
anssik: useful to have a rough indication, even if not closely accurate, good to have estimate
... up to implementer whether they want to use it
ISSUE: should charging time be retained in battery API if inaccurate
<trackbot> Created ISSUE-163 - Should charging time be retained in battery api if inaccurate. Please complete additional details at <http://www.w3.org/2009/dap/track/issues/163/edit>.
gmandyam: if implemented in OS does not mean it is necessary to support
ISSUE: correct default for charging time if unknown in battery
<trackbot> Created ISSUE-164 - Correct default for charging time if unknown in battery. Please complete additional details at <http://www.w3.org/2009/dap/track/issues/164/edit>.
gmandyam: something to consider, we might want to remove
anssik: leave it up to implementers
<dom> +1 on leaving it up to implementors
gmandyam: can leave up to implementers, perhaps add warning note to spec
ISSUE-163: leave up to implementers, perhaps add note warning possible innacurracy
<trackbot> Notes added to ISSUE-163 Should charging time be retained in battery api if inaccurate.
close ISSUE-163
<trackbot> Closed ISSUE-163.
RESOLUTION: not remove charging time from battery
ACTION-699?
<trackbot> ACTION-699 -- Giridhar Mandyam to Review battery and how low battery threshold is handled -- due 2014-06-19 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/699
gmandam: : did not check with Firefox OS team, drivers same as in open source project, so low power indication has to be created by higher level os
... complie time issue
... some developers would like to adjust threshold but cannot update
fjh: no spec change based on this action result
<gmandyam> Checked w/FF OS team - did not check with Tizen team. Any low power event would have to be created by the high level OS. The drivers do not provide this. In Android, the threshold for a low power event is fixed and determined at compile time.
anssik: platform defines low at compile time
fjh: does not sound useful, I'm asking why it is compiled in
<gmandyam> Any implementation of battery API would require an implementer (i.e. browser vendor) to create this event based on a threshold. It may not be that useful to developers, as they have no control over the threshold.
<anssik> http://www.w3.org/TR/2011/WD-battery-status-20110915/
anssik: had this attemped earlier, did not work, consistent with what gmandyam said
<scribe> ACTION: LisaDeluca_IBM to follow up with Cordova on result of discussion [recorded in http://www.w3.org/2014/06/26-dap-minutes.html#action01]
<trackbot> Error finding 'LisaDeluca_IBM'. You can review and register nicknames at <http://www.w3.org/2009/dap/track/users>.
<scribe> ACTION: lisa to follow up re closing January Cordova feedback [recorded in http://www.w3.org/2014/06/26-dap-minutes.html#action02]
<trackbot> ACTION-704 -- Lisa Seacat DeLuca to Follow up re closing january cordova feedback -- due 2014-07-03 -- OPEN (corrected after call)
<anssik> http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0068.html
fjh: this is message http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0068.html
... Add warning to Battery API that (naive) implementation of API could negatively affect battery life
anssi: agree to add this
ACTION-699?
<trackbot> ACTION-699 -- Giridhar Mandyam to Review battery and how low battery threshold is handled -- due 2014-06-19 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/699
close ACTION-699
<trackbot> Closed ACTION-699.
fjh: need to close out Tim's comments http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0070.html
anssik: mounir is active on this as well
<anssik> https://code.google.com/p/chromium/issues/detail?id=122593
fjh: maybe mounir can confirm that the issues are closed?
... we need confirmation from Tim or Mounir that Annsi's response looks good http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0070.html
<anssik> mounir, do you think you could see the implementation https://code.google.com/p/chromium/issues/detail?id=122593 matches the latest spec?
<anssik> ... or get Tim look at it :-)
fjh: are there any other open items on battery apart from what we've been through
anssik: no
http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0106.html
fjh: Thank you to Zhiqiang and Anssi for the updates and review and work on testing
... ImplementationStatus portion of wiki with table, move other stuff elsewhere
... please comment on list if concern
https://www.w3.org/2009/dap/wiki/User:Zqzhang/Test
<anssik> https://www.w3.org/2009/dap/wiki/ImplementationStatus
fjh: need to clarify difference of complete failure vs having a failure
<anssik> an example of test results: http://w3c.github.io/test-results/html-media-capture/all.html
fjh: this table is a very good improvement, very helpful and easier to understand
... from a high level I see that Vibration has 2 implementations and only one issue to resolve, others only have 1 implementation apart from HTML Media Capture which has comment noting more work is needed
... sent some feedback, apart from defining what test results mean would help to see overall status and whether there are failures at top level
ACTION-701?
<trackbot> ACTION-701 -- Zhiqiang Zhang to Provide summary of test status and next steps to dap wg -- due 2014-06-19 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/701
close ACTION-701
<trackbot> Closed ACTION-701.
close ACTION-523
<trackbot> Closed ACTION-523.
fjh: saw additional updates on list of approved tests, so directory of tests has been updated, this is good
ambient light update http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0085.html
vibration update http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0100.html
<anssik> https://github.com/w3c/web-platform-tests/
fjh: this is good to share summary updates on DAP list so we get informed when there is a change that we need to know about
... more detail on github see link from anssik
call for DAP Charter additions, deadline 7 July: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0082.html
Chartering considerations for Standby API http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0083.html
fjh: agree we have to be careful of detailed wording in charter, currently looking to see if we have other items
... reason for asking is to see if we can simplify process or need to
... we have informal and formal process, trying to get input early but then will use formal process to get input from AC etc
<dom> https://github.com/w3c-webmob/web-api-gap/
anssik: this could be input to discussion
dom: good source of information, need to get feedback from developers, implementers etc
anssik: maybe we should use dom's document as checklist
dom: will send message to web and mobile IG requesting input
fjh: TF item, has been dormant, renewed interest
... wishes work from Robin related
... need to figure out way forward, please join list discussion
<anssik> http://www.w3.org/2014/06/webapps-charter.html
dom: might have issue with Web Intents TF if WebApps does not include in revised charter, plan to drop from charter
fjh: we might want to include WebIntents in charter
dom: purpose initially was to give Web Intents attention, maybe not an issue now
fjh: ok
fjh: much good work is happening in this task force, process on existing specs, new work being considered
... information is on the DAP home page
... I have asked the TF chairs to share an update, will do so in the next week or two
anssik: what is the time frame and process for chartering
dom: charter expires at end of year, typically requires 2 months for the chartering process
... thus expect we will need a draft charter by end of October
fjh: we are looking now to see if there are additional charter items, apart from Standby API, by 7 July
... if only change is standby API clarification we are seeing if there is a lightweight quicker process to add it, that could happen much earlier if possible
anssik: regrets for July
dom: regrets 24 July
fjh: will cancel meetings as appropriate depending on agenda and regrets
fjh: I do not believe we need to give a generic action to Zhiqiang, he knows he is the testing facilitator and the status in the table.
ACTION-702?
<trackbot> ACTION-702 -- Anssi Kostiainen to Add paragraph to battery explaining model, update to 6.1 proposed by fjh -- due 2014-06-19 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/702
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
none