See also: IRC log
<trackbot> Date: 12 June 2014
<scribe> ScribeNick: fjh
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
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 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
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 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 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
<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
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
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
"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
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
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].
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
next call 26 June
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
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.
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
s/s;zakim who is here?;;//
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]