See also: IRC log
<trackbot> Date: 06 February 2014
<scribe> ScribeNick: fjh
Approve minutes from 30 January 2014
http://lists.w3.org/Archives/Public/public-device-apis/2014Jan/att-0056/minutes-2014-01-30.html
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
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: 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)/
http://dev.w3.org/2009/dap/vibration/LC3.html
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."
fjh: please notice that there is a list discussion regarding possible Standby API proposal
... thanks Dom for quick response
http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0001.html
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
<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-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: still ongoing
fjh: Pending
close ACTION-674
<trackbot> Closed ACTION-674.
close ACTION-678
<trackbot> Closed ACTION-678.
ISSUE-149?
<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
None