W3C

Device APIs Working Group Teleconference

26 Jun 2014

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, Clarke_Stevens, Dominique_Hazael-Massieux, Frederick_Hirsch, Giri_Mandyam, Mats_Wichmann, Cathy_Chan
Regrets
Chair
Frederick_Hirsch
Scribe
fjh

Contents


<trackbot> Date: 26 June 2014

Welcome, agenda review, scribe selection, announcements

Minutes approval

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 HTML Media Capture, Light, Vibration

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

Battery

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

Testing Status update

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

DAP Charter

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

Web Intents

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

Media Capture Task Force

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

Chartering

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

Upcoming Meetings

anssik: regrets for July

dom: regrets 24 July

fjh: will cancel meetings as appropriate depending on agenda and regrets

Action Items

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

Other Business

none

Adjourn

Summary of Action Items

[NEW] ACTION: lisa to follow up re closing January Cordova feedback [recorded in http://www.w3.org/2014/06/26-dap-minutes.html#action02]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $