Device APIs Working Group Teleconference

06 Feb 2014


See also: IRC log


Frederick_Hirsch, Mats_Wichmann, Anssi_Kostiainen, Lisa_DeLuca, Dominique_Hazael-Massieux, Giri_Mandyam


<trackbot> Date: 06 February 2014

Welcome, agenda review, scribe selection, announcements

<scribe> ScribeNick: fjh

Minutes approval

Approve minutes from 30 January 2014


fjh: please note that I annotated the minutes after the call to reflect an update regarding sending a CfC for Vibration and changing the date

RESOLUTION: Minutes from 30 January 2014 are approved


CfC for publishing LC completes today, plan to publish Tuesday, 11 Feb. please respond to CfC on list.

CfC: http://lists.w3.org/Archives/Public/public-device-apis/2014Jan/0055.html

publication draft: http://dev.w3.org/2009/dap/vibration/LC3.html


<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: some slight spec changes might be useful based on internal feedback, mostly editorial

… have shared with Anssi offlist

anssik: agrees changes are editorial

fjh: should share this on the public list

gmandyam: will send email to list outlining feedback and proposed changes

anssik: rephrasing of word of spec

gmandyam: pattern might not be possible if vibrator busy, driver provides this info, but on android driver does not provide this information

… not saying this should be provided to developer

… but if not android developer might have this information

… instead of saying "or it is disabled" say "or it is disabled or it is busy"

<anssik> "If pattern is an empty list, or if the device does not provide a vibration mechanism (or it is disabled), then return true and terminate these steps."

<anssik> Giri's proposal is to s/(or it is disabled)/(or it is disabled or busy)/


step 10

"If pattern is an empty list, or if the device does not provide a vibration mechanism (or it is disabled), then return true and terminate these steps."

<anssik> +1 on fjh's proposal

fjh: suggest " , or if device is unable to vibrate, then return true"

<gmandyam> +1 on fjh's proposal too

<dom> +1

<mats> +1

RESOLUTION: Adopt proposed change in LC draft

close ACTION-666

<trackbot> Closed ACTION-666.

anssik: updating LC draft now

<anssik> "If pattern is an empty list, or if the device is unable to vibrate, then return true and terminate these steps."

Standby API Specification proposal

fjh: please notice that there is a list discussion regarding possible Standby API proposal
... thanks Dom for quick response


fjh: suggest we wait a bit for implementer support for standardizing this
... if we decide to add this can do at any time?

dom: yes, rechartering also happens when charter expires

fjh: we need to make sure group members are ok with it from IPR perspective

dom: can have CfC to agree on re-chartering

gmandyam: sent an email, not sure DAP should be doing this given similar sys apps work

dom: we need to give some time and thought to whether we do this, based on implementer feedback

fjh: lets continue the discussion on the list

Network Service Discovery

<gmandyam> Summarized my concern abour rechartering DAP for this deliverable on the mailing list: this should be a two-step process, where the first step would be getting implementer feedback (which can be done in the DAP context) ...

fjh: Rich, Jean-Claude, Cathy not on list so need to defer
... need to address issue raised by Jean-Claude http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0016.html

<gmandyam> Based on the feedback, the second step should be to decide whether the work actually belongs in DAP WG (versus e.g. SysApps WG)

fjh: we need to determine plan for publishing updated WD, schedule for LC

… updated WD is appropriate given addition of CORS

… wanted to get some issues resolved before publishing

<Zakim> dom, you wanted to ask about WebAppSec

fjh: would like to publish an update

… do we need a CfC, could ask Rich first

dom: do not CfC

fjh: send request for review to WebAppSec and also Security IG, have not received a response

dom: might get better response without formal review request

… suggest we start with WebAppSec

fjh: I will follow up with Wendy and Brad

dom: have Rich present specifics of problem space
... not just about CORS, but exposing network devices without exposing devices

… expose general problem space

fjh: this came up on PING, the issue and problem of obscuring URLs for local network devices

<scribe> ACTION: fjh to follow up on WebAppSec review [recorded in http://www.w3.org/2014/02/06-dap-minutes.html#action01]

<trackbot> Created ACTION-680 - Follow up on webappsec review [on Frederick Hirsch - due 2014-02-13].

Action Review


<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: still ongoing

fjh: Pending

close ACTION-674

<trackbot> Closed ACTION-674.

close ACTION-678

<trackbot> Closed ACTION-678.



<trackbot> ISSUE-149 -- handling of long vibration list - truncate or no vibration at all -- closed

<trackbot> http://www.w3.org/2009/dap/track/issues/149

Other Business



Summary of Action Items

[NEW] ACTION: fjh to follow up on WebAppSec review [recorded in http://www.w3.org/2014/02/06-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 $