See also: IRC log
<trackbot> Date: 15 October 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/0023.html
<anssik> scribeNick: anssik
<fjh> Results of Vote on Media Capture and Streams Constraints Registry - https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/0021.html
<fjh> Web Platform WG replaces WebApps WG, http://www.w3.org/2015/10/webplatform-charter.html
fjh: vote on the mediacapture-main went through
... Web Platform WG is the new WebApps WG
<fjh> Approve minutes from 1 Oct 2015
<fjh> proposed RESOLUTION: Minutes from 1 Oct 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/att-0000/minutes-2015-10-01.html
RESOLUTION: Minutes from 1 Oct 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/att-0000/minutes-2015-10-01.html
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/0022.html
dom: integrated changes to the charter draft
... going through renewal process, W3C mgmt approval, AC review, before that three week CfC
... some changes may be controversial:
... 1) New Document and Software License enabling forking
... 2) Expedited process for adding new deliverables to the charter
... 3) Streamlining the existing deliverables list, remove inactive work, only exception being NetInfo API which has implementations
... 4) Use of asynchronous decision policy
fjh: does 4 mean we do not need to do CfCs?
dom: formally speaking we could do that, but better do explicit CfCs
... expedited process means we can update the charter with a new deliverable, and the W3C mgmt and AC review only
fjh: propose a two week CfC for the new charter
<fjh> proposed RESOLUTION: proceed with two week CfC for WG to approve proceeding with draft Charter distributed by Dom
RESOLUTION: proceed with two week CfC for WG to approve proceeding with draft Charter distributed by Dom
<fjh> two questions I raised privately re charter - 1) should group name change, eg Device APIs and Sensors (DAS)
<fjh> changing name can reflect change of the scope of the work of the group, a new focus, help others understand where this work is done
<fjh> makes it easier to market what is done
<fjh> dom: bluetooth won't move here, question about NFC still
<fjh> Sensors and media - SAM
<fjh> it should have the word Sensor in it
<fjh> suggest CfC is with understanding with group name could change
<fjh> Device Platform
<fjh> Device Sensor Platform
Device APIs and Sensors Working Group (DAS WG)
<fjh> why not "Device and Sensors Working Group"
<fjh> proposed RESOLUTION: use "Device and Sensors Working Group" in proposed charter
RESOLUTION: use "Device and Sensors Working Group" in proposed charter
<fjh> will include that in CfC
<fjh> Status and plans for Web Intents Task Force (was joint with WebApps but not mentioned in Web Platform charter)
<dom> [on the topic of Web Intents like discussion, it's restarting again :) http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/ ]
fjh: suggest we close the TF
... not on the Web Platform WG charter
dom: some blog posts on the topic published recently, regardless should pursue with closing
<fjh> ACTION: fjh to send CfC for 2 week approval of progressing with charter and name change [recorded in http://www.w3.org/2015/10/15-dap-minutes.html#action01]
<trackbot> Created ACTION-739 - Send cfc for 2 week approval of progressing with charter and name change [on Frederick Hirsch - due 2015-10-22].
<fjh> ACTION: fjh to send CfC to close Web Intents TF [recorded in http://www.w3.org/2015/10/15-dap-minutes.html#action02]
<trackbot> Created ACTION-740 - Send cfc to close web intents tf [on Frederick Hirsch - due 2015-10-22].
<lukasz> +1
fjh: FPWD published today, thanks Tobie
<fjh> WebI2C and WebGPIO https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/0015.html
tobie: would like to talk to Rick re the WebI2C and WebGPIO
... Rick seems to be opposing this low-level APIs, and prefers to see Bluetooth and Serial APIs for the Web instead
... a major issue is the security model that is different from the Web's
... nevertheless, an interesting area to explore
<fjh> breakout session
<fjh> http://www.w3.org/wiki/TPAC/2015/SessionIdeas#WebGPIO.2C_WebI2C_API
fjh: would be interesting to see the proceedings from the breakout session, please report back
tobie: I was starting to work on the proximity API to see if I can rewrite it on top of Generic Sensor API
... some sensors would like to get data out at regular intervals
... for some sensors, only when the change happens
... e.g. geolocation
... for device location will want to get low latency
... in Android, different API for different type of sensors
... wondering how to handle that in the Generic Sensor API
... should we have two different Generic Sensor APIs to cater for both cases?
<inserted> ScribeNick: fjh
anssik: ambient light might be better one to start with for modeling on top of generic sensor API
... we have experimental code
... many platforms use ambient light to implement proximity
tobie: this is like a higher level sensor then
<scribe> ScribeNick: anssik
https://w3c.github.io/ambient-light/
<lukasz> I'm currently in the process of writing a little doc on possible privacy issues in a bunch of APIs, starting to arrive on possibly interesting constructs/arguments [still I keep it at a far side in order not to interfer with the group's work/jeopardize anything] - hopefully will be of use
https://w3c.github.io/proximity/
<lukasz> I will try to minimize noise and report only when it has taken shape, then possibly ask for input, CC with PING group as well - perhaps a blueprint for privacy considerations will emerge + other avenues of work
<Zakim> fjh, you wanted to mention that both use cases are important, regular reporting and exception reporting, how to design open
<scribe> scribeNick: anssik
fjh: both use cases are important, regular reporting and exception reporting, how to design open
... propose both should be in the same spec
tobie: solved a bunch of issues, some issues still open
... that need to be added to the spec
... want to have issues triaged by TPAC; can we use the auto WD publication mechanism for generic sensor API
+1
+1 for echidna
dom: I can help setup echidna at TPAC
<fjh> I support using auto-WD publication for generic sensor API
fjh: no DAP meeting at TPAC, but there will be related ad hoc and break out sessions
<fjh> http://www.w3.org/2009/dap/minutes.html#upcoming-f2f
<fjh> http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences
Upcoming Teleconferences
15 October 2015, agenda
29 October 2015, cancelled (TPAC)
12 November 2015, agenda
26 November 2015, Cancelled (US Thanksgiving)
10 December 2015, agenda
24 December 2015, Cancelled (Christmas)
7 January 2015, agenda
<fjh> can we move the 10th Dec to the 3rd Dec
<fjh> everyone on call ok with it
<lukasz> +1
<fjh> proposed RESOLUTION: Cancel call on 10th Dec, schedule call 3 Dec
RESOLUTION: Cancel call on 10th Dec, schedule call 3 Dec
<fjh> none