See also: IRC log
<trackbot> Date: 25 June 2015
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0161.html
<scribe> ScribeNick: fjh
CfC to shelve Permissions API ends today, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0150.html
TPAC,http://www.w3.org/2015/10/TPAC/
fjh: looks like we can go ahead with publication tomorrow, if no concerns. I've prepared draft for publication Tue 2 July
dom: I can make the publication request
fjh: thanks
... TPAC breakout sounds good, thanks
fjh: Approve minutes from 11 June 2015
RESOLUTION: Minutes from 11June 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/att-0104/minutes-2015-06-11.html
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0156.html
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0163.html
fjh: battery testing still in progress thanks to Intel, need work on Mozilla to progress
anssik: person working on it in private branch
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0157.html
fjh: do we know which browsers based on webkit are offering this HTML Media Capture and can provide test results
anssik: code is in webkit, but work required for browser to use it
... we had blackberry browser, but that status of Blackberry OS is now unknown
... there are some forks
fjh: so we have an issue related to two implementations
anssik: is on chrome in android
... webkit places - apple, mozilla ok with accept attributes, similar but not exact, microsoft not clear
... maybe we should check with microsoft
... small amount of work with WebIDL to tie into platform
dom: should we stop having only one implementation or try to get others; question of whether to continue with this
... is it useful
anssik: can review use cases that are not addressed by accept attribute
dom: if using instagram don't want to use photo gallery, part of rationale
<scribe> ACTION: anssik to contact Mozilla and Microsoft re interest in implementing HTML Media Capture vs shelving [recorded in http://www.w3.org/2015/06/25-dap-minutes.html#action01]
<trackbot> Created ACTION-734 - Contact mozilla and microsoft re interest in implementing html media capture vs shelving [on Anssi Kostiainen - due 2015-07-02].
anssik: taking photo still hard on web platform if you need to use getUserMedia, so HTML Media Capture should be relevant
<anssik> https://bugzilla.mozilla.org/show_bug.cgi?id=741393
fjh: if we do not have interest then I will send a CfC to shelve, resulting in it being published as a Note and work stopped
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0158.html
fjh: looks like this work is progress
response, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/att-0168/00-part
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0169.html
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0159.html
fjh: we have choice, I think a lot depends on timing
... have not gotten much response to my question on the list
anssik: we need better idea by having generic api better developed and then seeing fit
dom: not sure if either in high demand, so can wait for a few months to decide
... most logical might be to build on generic sensor API
... I haven't heard concern about these two APIs being delayed or strong desire for them to move forward
... what is status of microsoft on these
anssik: ambient light under development accroding to microsoft web page, shared this with Adrian and Travis
... they are aware that we are working on the generic sensor API
fjh: summary - continue on generic sensor api path, with view toward moving Proximity and Ambient toward Generic Sensor API
dom: know no strong interest in current APIs, concerns from Mozilla, possibility of confusion
... suggest we make clear that we don't expect to continue these in the current approach
... current consensus of group is toward generic sensor
fjh: have only seen one response to my message, from Tobie
proposed RESOLUTION: CfC to return Proximity and Ambient light to WD noting that approach will be generic sensor API based
dom: suggest we publish with strong note that being based on Generic Sensor API
... not sure we should remove technical content
anssik: add notes to editors draft, not sure we need to publish
dom: it is important, some people are confused if TR does not match what is on our roadmap
... don't want announcement
... can publish using echidna (the new pub system)
anssik: moved ambient light, will do for proximity
<scribe> ACTION: anssik to create editor drafts for Ambient LIght and Proximity indicating new approach toward generic sensor API, also drafts for publication to TR space [recorded in http://www.w3.org/2015/06/25-dap-minutes.html#action02]
<trackbot> Created ACTION-735 - Create editor drafts for ambient light and proximity indicating new approach toward generic sensor api, also drafts for publication to tr space [on Anssi Kostiainen - due 2015-07-02].
<scribe> ACTION: fjh to send CfC for WD publication for Ambient Light and Proximity once drafts available [recorded in http://www.w3.org/2015/06/25-dap-minutes.html#action03]
<trackbot> Created ACTION-736 - Send cfc for wd publication for ambient light and proximity once drafts available [on Frederick Hirsch - due 2015-07-02].
anssi: what is up with device orientation spec, no progress in 15 months
dom: in May AC meeting disussed with Giri, unclear whether work will progress
<anssik> http://w3c.github.io/deviceorientation/spec-source-orientation.html
dom: we need to decide whether to continue or not, Giri will bring back to group
<anssik> https://github.com/w3c/deviceorientation
dom: also checking with staff contact for that group, have not heard
<anssik> DeviceOrientation Event Specification Editor's Draft 12 March 2014
dom: need to bring this up on geolocation mailing list
anssik: concern over use of DOM Events
... do we need a task force for sensor related specifications
dom: difference ambient light/proximity and device orientation is that device orientation is widely deployed and implemented
... should ask geolocation to finish standardization of current API
... then how and why to develop API on top of sensor API
... could do in DAP if agreed with geolocation wg
<anssik> +1
dom: reason is that not much interest in that group, and also developing generic sensor API, also rechartering
<dom_> ACTION: Dom to chat with Geo Chair and Staff contact on future of device orientaiton [recorded in http://www.w3.org/2015/06/25-dap-minutes.html#action04]
<trackbot> Created ACTION-737 - Chat with geo chair and staff contact on future of device orientaiton [on Dominique Hazaƫl-Massieux - due 2015-07-02].
request for comments, input: https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0149.html
dom: asks for review of proposal
... webapps and HTML re-arrangement, media likely to be separate