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*'
<mounir> s/;{/;)/
fjh: 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> Created ACTION-704 - Follow up re closing january cordova feedback [on Lisa Collichio - due 2014-07-03].
<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 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
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 Collichio to Follow up re closing january cordova feedback -- due 2014-07-03 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/704
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
s| s/;{/;)/\\
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/;{/;)/ Succeeded: s/mattersr/matters/ Succeeded: s/changed/spec change/ Succeeded: s/Zhiquiang/Zhiqiang/ Succeeded: s/Froce/Force/ Succeeded: s/dom/anssik/ Succeeded: s/mounir, is there a strong argument for either case from your point of view// WARNING: Bad s||| command: s| s/;{/;)/\\ No ScribeNick specified. Guessing ScribeNick: fjh Inferring Scribes: fjh Default Present: +1.720.934.aaaa, mats, dom, fjh, gmandyam, Clarke_Stevens, anssik, Lisa_DeLuca, Cathy Present: +1.720.934.aaaa Anssi_Kostiainen Clarke_Stevens Dominique_Hazael-Massieux Frederick_Hirsch Giri_Mandyam Lisa_DeLuca Mats_Wichmann anssik dom fjh gmandyam mats Cathy_Chan Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0084.html Found Date: 26 Jun 2014 Guessing minutes URL: http://www.w3.org/2014/06/26-dap-minutes.html People with action items: lisa lisadeluca_ibm WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]