See also: IRC log
<trackbot> Date: 12 December 2013
<scribe> ScribeNick: fjh
Welcome new members, http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0023.html
fjh: new member Ningxin interested in Media Capture , http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0025.html
anssik: yes he is interested in media capture and streams
fjh: will need to check on call schedule
dom: should point him to media capture task force list
fjh: i did this in the welcome message
... will send another message
... Call scheduled for next week 19 December; no teleconferences 26 Dec or 2 Jan, see http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences
Approve minutes from 21 November 2013
http://lists.w3.org/Archives/Public/public-device-apis/2013Nov/att-0030/minutes-2013-11-21.html
RESOLUTION: Minutes from 21 November 2013 are approved
fjh: Overview (with Rich) for Privacy Interest Group (PING) scheduled at next PING teleconference, 30 January 2014 9 am PT/noon ET, see http://lists.w3.org/Archives/Public/public-privacy/2013OctDec/0036.html
... we will start with overview to PING . They will review after the call.
cathy: will need to give regrets for the PING call due to vacation
fjh: WebAppSec call to be scheduled, http://www.w3.org/2011/webappsec/
... not sure we can do more on this topic until we have list discussion and/or call participation
cathy: agree
ACTION-671?
<trackbot> ACTION-671 -- Anssi Kostiainen to Prepare shelved note publications after tpac http://lists.w3.org/archives/public/public-device-apis/2013nov/0010.html -- due 2013-11-14 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/671
fjh: Publishing Moratorium: 8 December 2013 through 1 January 2014, see wiki http://www.w3.org/2009/dap/wiki/Main_Page#Administrativia
... would be good to prepare documents in advance, assuming you have work time, could plan to publish 9 January
anssik: this works, I can prepare the documents
Please continue discussion on list!
Chrome Apps discussion: http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0005.html
Mozilla discussion: http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0003.html
Abstraction proposal http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0007.html (Anssi)
Adaptor proposal http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0009.html (Josh)
Use Cases https://github.com/w3c-webmob/netinfo/ (Marcos)
Getting the correct problem statement: http://lists.w3.org/Archives/Public/public-device-apis/2013Dec/0017.html (Tobie)
<dom> Use case and requirements for network information
fjh: suggest looking at these various items, especially use cases and Tobie's message
dom: work marcos is doing is useful related to use cases
fjh: this is a fyi, please take a look and contribute on the list
anssi: agree to need for use cases
... lots of discussion
... webmob provides good use cases
fjh: discussion goes off in various directions
anssi: need stability over time, so if we say wifi now, maybe something different in the future
... my abstracting proposal offers future-proofing, but a tradeoff
gmandyman: need to remember hardware dependencies, e.g. a good bandwidth estimate cannot come out of the browser?
... stuff like Tobie talks about, batching and so on, are already addressed in mobile
... even with use cases need to consider target hardware platform, need to know which optimizations are possible
fjh: need to understand system and context, hard with privacy or optimizations to write specs in isolation for modules without considering integration into system
gmandyam: not always browser you are integrating into
fjh: lets continue this discussion on the list
... lets not lose your proposal and concerns on the list Anssi
anssik: need to make future proofing a requirement
... native apps depend on wifi availability, typically fastest and free
fjh: any updates on testing?
anssik: none from me
fjh: we can defer discussion of Network Service Discovery and Network Information API issues to list
... what about vibration issues
ISSUE-149?
<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/149
ISSUE-150?
<trackbot> ISSUE-150 -- Should vibration be additive when multiple instances, e.g. iframes -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/150
ISSUE-156?
<trackbot> ISSUE-156 -- add the [Clamp] attribute to the argument of the vibrate method -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/156
fjh: we had a problem with clamp, right
anssi: keyword not in WebIDL spec table yet
... still contoversial
ISSUE-156: defer until decision made for WebIDL spec regarding support for this, still not supported
<trackbot> Notes added to ISSUE-156 add the [Clamp] attribute to the argument of the vibrate method.
<gmandyam_> Re: Network Information. Qualcomm solution for TCP socket management in aggregate can be found at http://www.qualcomm.com/research/projects/traffic-management. My point was that use cases are not enough - any API that is designed independent of HW optimizations could result in a degradation in performance.
fjh: I'll review the vibration issues and send message to the list regarding status if needed
<scribe> ACTION: fjh to review status of vibration issues [recorded in http://www.w3.org/2013/12/12-dap-minutes.html#action01]
<trackbot> Created ACTION-672 - Review status of vibration issues [on Frederick Hirsch - due 2013-12-19].
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
anssik: need to check status on this with QA team, should have test suite feature complete, will check
ACTION-645?
<trackbot> ACTION-645 -- Frederick Hirsch to Share Network Service Discovery editors draft with PING -- due 2013-07-31 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/645
fjh: did this and scheduled meeting
close ACTION-645
<trackbot> Closed ACTION-645.
ACTION-654?
<trackbot> ACTION-654 -- Jean-Claude Dufourd to Propose text for network service discovery to define wildcard api and feature detection -- due 2013-09-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/654
cathy: proposal on list
close ACTION-654
<trackbot> Closed ACTION-654.
ACTION-657?
<trackbot> ACTION-657 -- Anssi Kostiainen to Revise battery tests for idlharness, find qa person to help -- due 2013-09-11 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/657
anssi: will check status, should be done
ACTION-654: link to JCD's proposal: http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0157.html
<trackbot> Notes added to ACTION-654 Propose text for network service discovery to define wildcard api and feature detection.
<anssik> https://github.com/w3c/web-platform-tests/tree/master/battery-status
ACTION-657: done, see https://github.com/w3c/web-platform-tests/tree/master/battery-status
<trackbot> Notes added to ACTION-657 Revise battery tests for idlharness, find qa person to help.
close ACTION-657
<trackbot> Closed ACTION-657.
ACTION-660?
<trackbot> ACTION-660 -- Anssi Kostiainen to Determine interest in progressing network information api or not -- due 2013-09-26 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/660
anssik: discussion on list has been good, some are spending time on this on list
fjh: DAP should not progress spec until we have implementation support and an idea of where to go, but we should be active on list discussing also with Google App list, webmob, and mozilla discussion etc
anssik: thanks to webmob for the work
... have done internal discussion, see value in API but want to start with use cases
ACTION-660: can see value in the API but want to start with use cases
<trackbot> Notes added to ACTION-660 Determine interest in progressing network information api or not.
close ACTION-660
<trackbot> Closed ACTION-660.
gmandyam: in sysapps wg working on connection API, should we see how that progresses first and then work on network information API?
anssik: sysapps api seems to be low level api like josh is proposing and I think DAP API should be more abstract, that might be a useful split
... seems to reflect charters of the groups
fjh: need to see how this is reflected in the DAP charter
... any idea of the sysapps time frame for that API?
anssik: not clear, there are higher priority items, needs work
... maybe should spec both and see which gets used
fjh: should include the various discussion lists but maybe a draft makes it easier to get feedback
ACTION-665?
<trackbot> ACTION-665 -- Anssi Kostiainen to Update vibration draft per action-652 -- due 2013-10-17 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/665
ACTION-652?
<trackbot> ACTION-652 -- Anssi Kostiainen to Make proposal on list regarding multiple vibration api invocations in frames for vibration -- due 2013-09-11 -- CLOSED
<trackbot> http://www.w3.org/2009/dap/track/actions/652
anssik: updated algorithm
close ACTION-665
<trackbot> Closed ACTION-665.
ACTION-666?
<trackbot> ACTION-666 -- Giridhar Mandyam to Check with internal implementers whether vibration api is consistent with chip capabilities -- due 2013-10-17 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/666
gmandyam: still working on this
... will post to the list after the holidays
ACTION-671?
<trackbot> ACTION-671 -- Anssi Kostiainen to Prepare shelved note publications after tpac http://lists.w3.org/archives/public/public-device-apis/2013nov/0010.html -- due 2013-11-14 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/671
fjh: may cancel the call next week unless we have new discussion items; please share status updates on the list
<mats> the link in ACTION-671 doesn't work
working link for ACTION-671: http://lists.w3.org/Archives/Public/public-device-apis/2013Nov/0010.html (fixed action after call,thanks for noting error)
fjh: please share Note publication drafts on list for review before publication, suggest creating template, reviewing and then updating
<anssik> http://www.w3.org/TR/WD-acss
email http://lists.w3.org/Archives/Public/public-device-apis/2013Nov/0023.html
language for shelving, http://dev.w3.org/2009/dap/calendar/
<anssik> "The Device APIs Working Group is currently not pursuing the approach outlined in this draft, so it should be considered historical. Please treat this document with caution and do not reference it or use it as the basis for implementation. The domain covered by this document is still within the scope of the Working Group as defined in its Charter. The
<anssik> Working Group may pursue an alternative API design that is based on the current Web browser security model."
<anssik> perhaps leave out "The Working Group may pursue an alternative API design that is based on the current Web browser security model"
fjh: suggest: "Work on this document has been discontinued and it should not be referenced or used as a basis for implementation." instead of "This document has been superseded."
... new paragraph: This is a historical document. The domain covered by this document is still within the scope of the Working Group as defined in its Charter."
... please share template with me, I can review and then we can go forward
... if we do not have a call next week have a Merry Christmas/good holiday