W3C

Device APIs Working Group Teleconference

04 Sep 2014

Agenda

See also: IRC log

Attendees

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

Contents


<trackbot> Date: 04 September 2014

<scribe> ScribeNick: fjh

Welcome, agenda review, scribe selection, announcements

Reminder, TPAC registration is open (however, DAP has no plans to meet) http://www.w3.org/2014/11/TPAC/

Minutes approval

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

CR publication of HTML Media Capture, Vibration

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 Battery publication

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].

Ambient Light

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

Wake Lock

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

Charter planning

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].

Network Service Discovery

<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

Meeting Schedule

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 and Issue review

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.

Cordova

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

Adjourn

Summary of Action Items

[NEW] ACTION: dom to add rwalron as invited expert to DAP group [recorded in http://www.w3.org/2014/09/04-dap-minutes.html#action03]
[NEW] 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]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

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