Device APIs Working Group Teleconference -- 15 Oct 2015

<trackbot> Date: 15 October 2015

Welcome, scribe selection, agenda review, announcements

<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

Minutes approval

<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

Charter

<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

Web Intents Task Force

<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

Generic Sensor API

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 for echidna

dom: I can help setup echidna at TPAC

<fjh> I support using auto-WD publication for generic sensor API

Upcoming meetings

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-teleconferences

<dom> s/at and during/

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

Other Business

<fjh> none

- DRAFT -

Device APIs Working Group Teleconference

15 Oct 2015

Attendees

Contents