W3C

- DRAFT -

Device APIs Working Group Teleconference

12 Jun 2014

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, Cathy_Chan, Clarke_Stevens, Frederick_Hirsch, Giri_Mandyam, Lisa_DeLuca, Marcos_Caceres, Mats_Wichmann, Rich_Tibbett, Dominique_Hazael-Massieux
Regrets
Ilya_Bogdanovich
Chair
Frederick_Hirsch
Scribe
fjh

Contents


<trackbot> Date: 12 June 2014

<scribe> ScribeNick: fjh

Welcome, agenda review, scribe selection, announcements

s;zakim who is here?;;

Welcome to new group participants:

Ilya (Yandex) http://lists.w3.org/Archives/Public/public-device-apis/2014May/0063.html

Yuan (Microsoft) http://lists.w3.org/Archives/Public/public-device-apis/2014May/0062.html

Zhiqiang (intel), Mikio (Mitsubishi Electric) http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0018.html

Publishing moratoria for end of 2014 : http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0001.html

Minutes approval

Approve minutes from 15 May 2014

http://lists.w3.org/Archives/Public/public-device-apis/2014May/att-0022/minutes-2014-05-15.html

RESOLUTION: Minutes from 15 May 2014 are approved

Vibration

Vibration API CfC: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0026.html

Plan to publish 19 June with LC End 25 July (5 weeks)

fjh: anssik we will need to prepare snapshots for publishing, including adding diffs, pubrules check, link check etc
... need to give time for publication request

anssik: can do this by ET monday morning

fjh: great, thanks
... all, if you haven’t looked at the various CfCs please do so, ends tomorrow

Light

Vibration API CfC: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0026.html

fjh: CfC on list ends tomorrow
... no comments, so good to go

HTML Media Capture

HTML Media Capture CfC; http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0028.html

fjh: minor typo found by Cathy, http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0056.html
... other than that, no issues, so should be included

Battery

Battery CfC; http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0029.html

fjh: some editional proposed edits based on Tim’s comments: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0048.html
... I also had comment on default

anssik: if unknown or unable to report values use default of full, eases development
... before sync provided, always had to provide value, but now using promises, so if don’t know how, can not resolve promise
... also had fingerprinting concern
... if battery is full can do everything, if low cripple experience, so iif we don’t know use full battery so not to disable experience

fjh: we need a paragraph exlaining this model, reader would not know
... I don’t believe this one is ready for last call, need to let it settle, do you agree

anssik: yes, I think we need feedback from Tim

marcos: the spec is probably good enough as it is
... haven’t seen impact on performance, depends on implementation or hardware

gmandyam: firefox only doing what is in kernal, there is more that can be done, for example with qualcom extensions to the OS for example

<marcosc> for example: https://bugzilla.mozilla.org/show_bug.cgi?id=890715

gmandyam: misleading, since there could be better

<gmandyam> Will clarify: browser can implement a power monitor using non-kernel approaches, e.g. Intel's PMIC proposal in TPAC 2013

<gmandyam> See https://docs.google.com/presentation/d/1lpOlTtq93XtPCtZNsX00zmSJ6idO79I6SHkzMJKLUzU/edit#slide=id.g295cff55f_2_75

fjh: to clarify, I’m not suggesting we rework the spec, just wanted Anssi to add some clarification text regarding the model, and a few notes to clarify for Tim’s comments.
... anssik may have more to add on this, do not want to hold up LC
... josh concerns may be valid in some cases, may be implementation dependent

<anssik> http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0044.html

<anssik> https://dvcs.w3.org/hg/dap/rev/7476e089d3d9

anssik: if system unable to report charging time or discharging time, can it report default?

<gmandyam> To clarify: agree with Josh Soref's comment about the low power event being the most important part of the existing API (assuming I understood him correctly). I believe the code example in the spec is misleading, as developers will not likely trust the API to modify networking behavior of the app.

anssik: Tim suggests that if cannot report some values should default from all values, but could be handled individually

<gmandyam> However, developers generally trust the low power event. In my experience, HW vendors have implemented it fairly well and it will allow the app to do whatever needs to be done prior to the phone shutting down.

fjh: how do you distinguish between default value and real value?

<gmandyam> We should adjust the code example in the spec reflecting this case, and put in special mention on conformance for this feature in particular.

<anssik> https://dvcs.w3.org/hg/dap/rev/7476e089d3d9

fjh: to summarize, I believe you are saying we should treat each value independently, as far as able to report real values or not

anssik: I am proposing this edit

<anssik> fjh: correct

<scribe> ACTION: gmandyam to review battery and how low battery threshold is handled [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action01]

<trackbot> Created ACTION-699 - Review battery and how low battery threshold is handled [on Giridhar Mandyam - due 2014-06-19].

<anssik> http://www.w3.org/TR/2011/WD-battery-status-20110915/

anssik: we are starting to revisit previous decisions, have implementations

marcos: can base event on current API to do this

gmandyam: not clear to developer that hardware will be shutting down soon

marcos: can you really do this
... I have done this, have github example

fjh: what was your concern with the examples

marcos: not a major concern, look too complicated

anssik: examples could be simple, may rearrange

<scribe> ACTION: anssik to propose example revisions for battery [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action02]

<trackbot> Created ACTION-700 - Propose example revisions for battery [on Anssi Kostiainen - due 2014-06-19].

<gmandyam> fjh - I have to sign off now. Please assign an action item to me re: examine current battery API to see how low power event could be mimic'ed.

<marcosc> gmandyam, see https://github.com/marcoscaceres/playground/blob/gh-pages/flexbox/keypad.html#L233

<anssik> battery status playground -> http://anssiko.github.io/battery-status/

fjh: so it is decided to defer battery LC until we have resolved issues raised on list and call

Proximity

<marcosc> example battery indicator: http://marcoscaceres.github.io/playground/flexbox/keypad.html

Proximity waiting on implementer interest/use cases: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0019.html

fjh: need more implementer interest in proximity before we can proceed

anssik: maybe can learn from ambient light implementation, agree with waiting for interest

fjh: any action we should take

anssik: some think this can be implemented with ambient light

fjh: maybe depend on hardware details

dom: not always appropriate to use light as substitute for proximity API
... webRTC is likely to use proximity API
... fine to wait and revisit, maybe ask Mounir

anssik: gaming is another potential area to use this API
... we need to see if people get what they need using ambient light

Network Service Discovery

sent summary and updated questions to Web & TV group http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0012.html

added issues based on Youenn feedback: http://lists.w3.org/Archives/Public/public-device-apis/2014May/0029.html

All DAP issues are NSD issues: http://www.w3.org/2009/dap/track/issues/open

richt: would like to get more feedback on NSD, including UpNP

cathy: perhaps Clarke Stevens has some feedback from that community

<LisaDeLuca_IBM> > Hey > > After the battery tests, I looked at the battery plugin, and we need > to shelve the battery plugin until we get a new API. Worse yet, the > W3C API proposed is terrible and should never be implemented on > Android. > > So, as we currently implement it, we set the battery to listen to the > batteryChange event, which is used to return the battery level, which > isn't actually a percent but some number that isn't consistent across > A[CUT]

<LisaDeLuca_IBM> email from the cordova mailing list related to battery

<LisaDeLuca_IBM> just saw it

Clarke: need to be able to local discovery, NSD is not the only manner, we should also look at alternative

Named Web Sockets

see http://lists.w3.org/Archives/Public/public-device-apis/2014May/0032.html

richt: alternative to NSD is lighter weight named web sockets
... currently uses DNS service discovery, Bonjour
... similar to broadcast channel

<LisaDeLuca_IBM> here is the cordova dev list thread that talks about some of the issues with the battery spec: http://apache.markmail.org/search/?q=org.apache.incubator.callback-dev+list%3Aorg.apache.incubator.callback-dev+order%3Adate-backward+battery+plugin+api+drains#query:org.apache.incubator.callback-dev%20list%3Aorg.apache.incubator.callback-dev%20order%3Adate-backward%20battery%20plugin%20api%20drains+page:1+mid:4auqqxne2pfvnpm2+state:results

richt: handles lots of use cases, based on pre-agreed key to establish channel
... enables collaboration without centralized authority
... lots of functionality is enabled without much complexity
... another use case is to bootstap 2nd screen sharing

fjh: builds on top of web sockets

richt: do not need to reinvent things
... this was born out of need to simplify, and also to address user need to opt in, this is more ad hoc, limited awareness since need to know shared names

fjh: might need to make hard to guess names

richt: certainly possible

anssik: is this similar to BroadcastChannel, new feature in HTML

richt: cross origin and cross user agent capabilities are new

Standby API and Charter

"Proposed approach to progressing Standby API with respect to DAP Charter” http://lists.w3.org/Archives/Public/public-device-apis/2014May/0077.html

<dom> BroadcastChannel

Standby API

Start of thread, initial proposal attached: http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0001.html (Dariel Marlow)

Info on implementation work http://lists.w3.org/Archives/Public/public-device-apis/2014May/0034.html (Anssi)

Related earlier technical work http://lists.w3.org/Archives/Public/public-device-apis/2014May/0038.html (Anssi)

Dom Proposal http://lists.w3.org/Archives/Public/public-device-apis/2014May/0049.html

Marcos alternative proposal http://lists.w3.org/Archives/Public/public-device-apis/2014May/0054.html

fjh: suggest we continue this on the list

<marcosc> +q

dom: my first proposal is not meeting need for API, need to decide on programmatic versus declarative, seems to be most interest in proposals 2 and 3

marcos: no strong opinion on API, need to flesh out the use cases
... not finding a lot of apps that do this, so not sure how much of a need there is for this API
... need to look at more apps to find real examples for API use
... have been looking at ios apps

anssik: I have a voip phone that keeps screen on all the time

marcos: lets find the use cases first then the API that fits

dom: bring back to WebMob

marcos: this has no huge rush so we should gather more input
... we should do a document like for NetInfo, can you, me, Dom do this

anssik: yes
... seems that this API could be premature at this point

marcos: agreed

Testing & Implementations

Test Facilitators: Zhiqiang volunteered for all apart from Battery. Marcos volunteered for battery.

Status update and next steps? http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0016.html

<scribe> ACTION: zhiquiang to provide summary of test status and next steps to DAP WG [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action03]

<trackbot> Error finding 'zhiquiang'. You can review and register nicknames at <http://www.w3.org/2009/dap/track/users>.

<scribe> ACTION: Zhiqiang to provide summary of test status and next steps to DAP WG [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action04]

<trackbot> Created ACTION-701 - Provide summary of test status and next steps to dap wg [on Zhiqiang Zhang - due 2014-06-19].

Cordova update

lis: met with Dom last week regarding spec alignment, decided to start with Vibration as use case to show alignment

lisa: 4 APIs not in Cordova that are in spec, identified gaps, created Jira issues for Cordova committers

<dom> https://github.com/MSOpenTech/cordova-api-audit/compare/w3

lis: monthly cordova call, microsoft and mozilla have been doing alignment checks, should make it easier
... next step is developers update

fjh: degree of implementer interest

lisa: new developers are looking for work shoudl be able to help
... will send email updates as appropriate

Other Business

next call 26 June

Action Items

ACTION-523?

<trackbot> ACTION-523 -- Anssi Kostiainen to Work on test cases for battery, vibration, and HTML Media Capture -- due 2012-08-31 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/523

Pending Actions

ACTION-689?

<trackbot> ACTION-689 -- Frederick Hirsch to Send cfc to update html media capture with proposal for security/privacy consideration, 1 week cfc -- due 2014-05-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/689

close ACTION-689

<trackbot> Closed ACTION-689.

ACTION-690?

<trackbot> ACTION-690 -- Frederick Hirsch to Reply to youenn re use cases etc -- due 2014-05-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/690

close ACTION-690

<trackbot> Closed ACTION-690.

ACTION-691?

<trackbot> ACTION-691 -- Frederick Hirsch to Make cfc to update battery and do another lc per suggested changes from google -- due 2014-05-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/691

close ACTION-691

<trackbot> Closed ACTION-691.

ACTION-692?

<trackbot> ACTION-692 -- Frederick Hirsch to Send cfc to remove light level event from ambient light, return to lc -- due 2014-05-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/692

close ACTION-692

<trackbot> Closed ACTION-692.

ACTION-693?

<trackbot> ACTION-693 -- Frederick Hirsch to Send message to confirm firefox status and plans to update for vibration -- due 2014-05-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/693

close ACTION-693

<trackbot> Closed ACTION-693.

ACTION-695?

<trackbot> ACTION-695 -- Frederick Hirsch to Check with microsoft dap members regarding plans for implementation and interop participation -- due 2014-05-22 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/695

close ACTION-695

<trackbot> Closed ACTION-695.

ACTION-696?

<trackbot> ACTION-696 -- Mounir Lamouri to Update battery draft to incorporate promises change, add promises reference, update status section, spell check/link check/validation check. (cfc already approved for these changes) -- due 2014-06-12 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/696

close ACTION-696

<trackbot> Closed ACTION-696.

ACTION-697?

<trackbot> ACTION-697 -- Anssi Kostiainen to Update html media capture editors draft with updated status section, spell check/link check/validation check -- due 2014-06-12 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/697

close ACTION-697

<trackbot> Closed ACTION-697.

ACTION-698?

<trackbot> ACTION-698 -- Anssi Kostiainen to Update ambient light api editors draft to remove lightlevelevent (involves removing section 6 as well as updating other sections), update status section, spell check/link check/validation check -- due 2014-06-12 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/698

close ACTION-698

<trackbot> Closed ACTION-698.

Other business

next call 26 June

fjh: to reiterate, Anssi will prepare 3 publication drafts including validation, link check, pubrules and adding diff links to sotd for monday morning ET - Vibration, Light, HTML Media Capture
... Giri has action to review battery , Anssi to add changes proposed by fjh, add paragraph to explain model, review feedback from Tim

<scribe> ACTION: anssik to add paragraph to battery explaining model, update to 6.1 proposed by fjh [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action05]

<trackbot> Created ACTION-702 - Add paragraph to battery explaining model, update to 6.1 proposed by fjh [on Anssi Kostiainen - due 2014-06-19].

<scribe> ACTION: anssik to prepare 3 publication drafts including validation, link check, pubrules and adding diff links to sotd for monday morning ET - Vibration, Light, HTML Media Capture [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action06]

<trackbot> Created ACTION-703 - Prepare 3 publication drafts including validation, link check, pubrules and adding diff links to sotd for monday morning et - vibration, light, html media capture [on Anssi Kostiainen - due 2014-06-19].

fjh: all please review Named Web Sockets
... Marcos, dom and anssi to review applications for Standby API use case confirmation

Adjourn

s/s;zakim who is here?;;//

Summary of Action Items

[NEW] ACTION: anssik to add paragraph to battery explaining model, update to 6.1 proposed by fjh [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action05]
[NEW] ACTION: anssik to prepare 3 publication drafts including validation, link check, pubrules and adding diff links to sotd for monday morning ET - Vibration, Light, HTML Media Capture [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action06]
[NEW] ACTION: anssik to propose example revisions for battery [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action02]
[NEW] ACTION: gmandyam to review battery and how low battery threshold is handled [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action01]
[NEW] ACTION: Zhiqiang to provide summary of test status and next steps to DAP WG [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action04]
[NEW] ACTION: zhiquiang to provide summary of test status and next steps to DAP WG [recorded in http://www.w3.org/2014/06/12-dap-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/06/12 15:27:25 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Succeeded: s/BroadCast channel/BroadcastChannel/
Succeeded: s/is this a/is this similar to/
Succeeded: s/??/WebMob/
Succeeded: s/did I miss where we were no longer doing alternating weeks?//
Succeeded: s/zakim who is here?//
FAILED: s/s;zakim who is here?;;//
Succeeded: s/nad mozilla habe /and mozilla have /
Succeeded: s/alighment/alignment/
Succeeded: s/develppers/developers/
Succeeded: s/appropraite/appropriate/
Succeeded: s/reminder: Lisa's Apache Cordova update at the end of agenda//
Found ScribeNick: fjh
Inferring Scribes: fjh
Present: Anssi_Kostiainen Cathy_Chan Clarke_Stevens Frederick_Hirsch Giri_Mandyam Lisa_DeLuca Marcos_Caceres Mats_Wichmann Rich_Tibbett Dominique_Hazael-Massieux
Regrets: Ilya_Bogdanovich
Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Jun/0030.html
Found Date: 12 Jun 2014
Guessing minutes URL: http://www.w3.org/2014/06/12-dap-minutes.html
People with action items: anssik gmandyam zhiqiang zhiquiang

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]