See also: IRC log
<trackbot> Date: 04 September 2014
<scribe> ScribeNick: fjh
Reminder, TPAC registration is open (however, DAP has no plans to meet) http://www.w3.org/2014/11/TPAC/
Approve minutes from 21 August 2014
http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/att-0050/minutes-2014-08-21.html
RESOLUTION: Minutes from 21 August 2014 are approved
Plan publication Tue 9 Sept, crEnd 12 Nov 2014 ; http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0010.html
Vibration test cases updated http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0007.html
test cases approved http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0008.html
fjh: CR approved, I have made the publication request. Can we move to PR quickly once crEnd
dom: to go to PR we need to make test suite complete for Vibration
fjh: we need a transtion call for PR
dom: yes, need to prepare that
... question of how and why applies to implementations without vibrator
... know spec speaks to it
<dom> dom: we should document in our implementation report how desktop browsers implement the vibration API
<dom> ... (where presumably there is no vibrator)
fjh: anssik are you able to document this?
anssik: desktop browsers don't ship with vibration hardware, as long as test shows green in test report, that should be enough
dom: need to document that we've verified that they work correctly , need to add column in implementation report for 1 or 2 desktop browsers
<scribe> ACTION: Zhiqiang to update implmentation report to clarify explicitly which tests are for desktop or mobile [recorded in http://www.w3.org/2014/09/04-dap-minutes.html#action01]
<trackbot> Created ACTION-714 - Update implmentation report to clarify explicitly which tests are for desktop or mobile [on Zhiqiang Zhang - due 2014-09-11].
dom: have two separate tables, one for devices with a vibrator, and one for devices without, e.g. desktop
ACTION-714: have two separate tables, one for devices with a vibrator, and one for devices without, e.g. desktop
<trackbot> Notes added to ACTION-714 Update implmentation report to clarify explicitly which tests are for desktop or mobile.
<anssik> http://w3c.github.io/test-results/vibration/all.html
ACTION-714: verify and add note to implementation report that desktop devices also pass tests
<trackbot> Notes added to ACTION-714 Update implmentation report to clarify explicitly which tests are for desktop or mobile.
dom: anssi, will you be working with Zhiqiang on this
anssik: yes, will talk to him
fjh: also please thank him for the test case work
LC published, LC ends 2 Oct http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0068.html
LC-2965, https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-battery-status-20140828/2965
fjh: concern discussed on list whether there should be separate APIs or larger sensor API
... responded, added wiki with history and rationale:http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0012.html
... do not think we need to restart, we have already progressed, new design in v.next could be used
<dom> dom: agreed we should proceed with the API as is
dom: agree to not restart, have two implementations
<dom> ... might not be perfect, but there is inteerst from 2 implementors with the API as is
<Zakim> dom, you wanted to mention remark on security reviews and to move to PR
<dom> ... we can always look into a v2 API if needed
anssik: agree with dom, no technical issue that needs to be fixed, more a matter of taste, not a good reason to restart so late in game
fjh: time to respond to LC comment
dom: CfC might be approriate
fjh: will do CfC
<scribe> ACTION: fjh to send CfC to close LC-2965 with proposal to continue existing Battery API with v.next if needed [recorded in http://www.w3.org/2014/09/04-dap-minutes.html#action02]
<trackbot> Created ACTION-715 - Send cfc to close lc-2965 with proposal to continue existing battery api with v.next if needed [on Frederick Hirsch - due 2014-09-11].
ISSUE-170?
<trackbot> ISSUE-170 -- light levels are not retrievable until a change causes the devicelight event to fire. -- open
<trackbot> http://www.w3.org/2009/dap/track/issues/170
see http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0058.html
fjh: this thread has been progressing but seems to have stopped
... this work is taking time since we only have one implementation
... any more action we can do
<anssik> https://github.com/rwaldron/sensors
anssik: waiting for more input, have seen concrete proposal
… some issues, cannot describe in WebIDL, non global constructors for example
… but most complete re-design we have now
… WebIDL is limited for javascript
fjh: I think WebIDL should be make Javascript specific and enhanced in that way, but this is an aside
anssi: suggestions?
dom: should use WebIDL where you can, best practice when you cannot use it, suggest changes to WebIDL
… otherewise use prose if needed
anssi: elsehwere any constructor that is not a global, cannot find precedent
<anssik> Sensor.AmbientLight
anssik: this is a contructor, cannot define in WebIDL
dom: can't you ???
anssik: looked on mailing list, ,found some similar needs elsehwere, did not see solution
dom: then you know more than me
... ask on public-script-coord
anssik: big backlog of WebIDL features
dom: ask on public-script-coord list, and use prose for now
<scribe> ACTION: dom to add rwalron as invited expert to DAP group [recorded in http://www.w3.org/2014/09/04-dap-minutes.html#action03]
<trackbot> Created ACTION-716 - Add rwalron as invited expert to dap group [on Dominique Hazaël-Massieux - due 2014-09-11].
anssik: could ask him to co-edit if interest as well
dom: ok, will work with him
Discussion is happening on public-script-coord list until 1st DAP submission draft ready, see
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/
fjh: I've asked if this should come on the DAP list, marcos suggested it stay there until a submission draft is ready
... so follow that list if interested for now
fjh: repeat of what I said on last call
<anssik> re "An API for requesting and managing user permissions to use device features"
Charter expires year end, revised draft charter needed by end of October.
request for input: http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0042.html
Discussion - need for broader changes; plans for addition of new deliverables (discuss CfC for individual additions)
fjh: so far I'm not hearing a call for broader changes
anssik: in community there is interest toward permissions API
<dom> Mounir's proposal on Permissions API
… might want to consider including
<dom> (our latest work on a permission API http://dev.w3.org/2009/dap/api-perms/)
fjh: my understanding is that Mounir's proposal is a very thin layer, not defining the mechanism of permissioning underneath, but rather providing an API to unify handling of prompts or whatever is underneath
anssik: yes
fjh: so different than what DAP started with, but in scope of DAP
anssik: could consider
fjh: already in charter
dom: no need to change charter
anssik: what is degree of implementer interest
dom: apple not member of group, but not clear
fjh: we can let this deveop on the list, any action needed?
dom: should note on WebApps list that DAP can do this if needed, already in charter
<scribe> ACTION: fjh to note on WebApps list that this is alreadyin DAP charter, so could be done in DAP if needed, Permissions API [recorded in http://www.w3.org/2014/09/04-dap-minutes.html#action04]
<trackbot> Created ACTION-717 - Note on webapps list that this is alreadyin dap charter, so could be done in dap if needed, permissions api [on Frederick Hirsch - due 2014-09-11].
<dom> Rich summary of NSD status
http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0018.html
dom: mail ends with questions
So feedback from group participants - both implementers and developers
- would be welcome on the following questions:
1. Is generic network service discovery and communications
bootstrapping important for the web?
2. Does this group want to continue working on a generic network
service discovery and communications bootstrap mechanism?
3. Does this group want to continue working on this against the
current API proposal [2]?
4. Have we reasonably addressed the above security concerns for the
current API proposal [2]?
5. Does anyone have additional plans and/or a roadmap to share
relating to this feature?
dom: might want some feedback from Web & TV group
... rich can provide some implementer interest feedback
... group response/thread to message
Next meeting, scheduled for 18 Sept, http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences
proposal to cancel 16 Oct and 30 Oct (TPAC)
Suggestion - schedule call for 9 Oct
<dom> works for me
<mats> +1 for me
RESOLUTION: cancel 16 Oct and 30 Oct teleconferences, add teleconference 9 Oct
ACTION-712?
<trackbot> ACTION-712 -- Dominique Hazaël-Massieux to Look into chartering extensibility -- due 2014-08-28 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/712
fjh: how to add deliverables once we have existing charter
ACTION-711?
<trackbot> ACTION-711 -- Dominique Hazaël-Massieux to Arrange director transition call for cr for html media capture, light, vibration before 28 aug planned publication date -- due 2014-08-28 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/711
close ACTION-711
<trackbot> Closed ACTION-711.
ACTION-713?
<trackbot> ACTION-713 -- Frederick Hirsch to Follow up on status of network service discovery and plans going forward, also named web sockets -- due 2014-08-28 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/713
close ACTION-713
<trackbot> Closed ACTION-713.
lisa: all vibration changes are live for Cordova, vibration fully aligned, now will look at Battery status
dom: anything we can do to help with battery?
lisa: will see degree of alignment, summarize and then ask for help