See also: IRC log
<trackbot> Date: 03 September 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0021.html
<fjh> ScribeNick: fjh
fjh: the /TR style sheet response sent: https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0021.html
... I submitted the style sheet response
... TPAC reminder (no DAP F2F): http://www.w3.org/2015/10/TPAC/
... who will be leading breakout session at TPAC
anssik: I will be there, expect Tobie as well, Giri you might wish to join
[Note - moved Device Orientation discussion to its own topic
fjh: Welcome to new members: Dapeng Liu, Rong Zhang (Alibaba), Rijubrata Bhaumik (Intel), Alexandra Mikityuk (Deutsche Telekom), Josh Soref (IE)
... Viacom has also joined (no participant)
dom: need to look into this
fjh: participants list - http://www.w3.org/2000/09/dbwg/details?group=43696&public=1&order=org
dapeng: from Alibaba group, working in standards group
... interested in all of the work of this group
fjh: do you plan to contribute to implementation and testing
dapeng: no plans yet, but would like to help with testing
anssi: Rijubrata contributing to Chromium, working on browser code, will be implementing some of the sensor APIs
fjh: Proximity and Ambient Light Event API WDs published, with warning that moving toward generic sensor API
https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0002.html
giri: put out call for future information on device orientation, got no response
... Rich left Opera
... should close issue
anssik: will device orientation move
giri: first want LC, but Apple still not compliant so an issue
... need LC first
... this does not stop revising device orientation under the generic sensor API
tobie: have looked over the last two weeks looking at device orientation to get sense for use cases for generic sensor API
dom: geolocation WG had no objection to DAP taking over device orientation so we should add to charter
<anssik> +1
fjh: +1
<tobie> +1
Approve minutes from 25 June 2015
proposed RESOLUTION: Minutes from 25 June 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/att-0175/minutes-2015-06-25.html
RESOLUTION: Minutes from 25 June 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/att-0175/minutes-2015-06-25.html
https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0149.html
<anssik> http://w3c.github.io/dap-charter/DeviceAPICharter.html
<dom> https://github.com/w3c/dap-charter/issues
fjh: There is a pull request regarding licensing
https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0003.html
fjh: Please review the charter
dom: if there are new work items to add, now is a good time to do so
... would like to finailize the charter by the end of this month
... please look at the charter, look at the open issues, consider new items that should be added to the charter
fjh: Draft updated for privacy considerations: https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0011.html
... thanks Anssi for updating draft for privacy consideration
... Mozilla update, need for test harness update?
https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0018.html
fjh: test harness does not handle promises
anssi: yes idl harness needs to be updated, sent mail, awaiting response, could work around it
fjh: follow up with James next week?
anssi: they need to figure it out
<dom> ScribeNick: dom
<tobie> http://w3c.github.io/sensors/usecases.html
tobie: basically, we came to the conclusion a couple of weeks ago that it was hard to get to consensus on the exact API design
... because they were hard to express in WebIDL
... I realized that having code examples based on use cases would help
... the idea of the use cases doc is to document real-world applications related to sensor work
... and also look at building polyfills for existing APIs
... I've worked on two such apps based on GH discussions
<tobie> http://w3c.github.io/sensors/examples/realtime-positioning/index.html
tobie: the first one is real time positioning on a map using geolocation
... it's not completely finished but it already brought me to interesting conclusions on sensor frequency
... one of the keys is to try to minimize the battery consumption
... so you need some indication on how often the sensor should be probed
giri: we have had agreement for device orientation
... built on sensor api
... I don't think there is such an agreement for geolocation
... not sure my company would agree to it
... we can use it as a use case, but I don't want us to commit to move geo to this model
tobie: good point
anssi: there can always be a polyfill in any case
... and it informs our design
fjh: right; but we should make clear that we're not saying geo will move to that model
[an issue will be raised in github to track this]
tobie: there has been a bunch of issues raised on generic sensors based on the experience with the geolocation API
... that's why I started looking at it in more details
... example of issues include accessing cached data
<tobie> http://w3c.github.io/sensors/examples/cached-data/index.html
tobie: the 2nd example is in fact based on this cached data aspect
... combined with looking at the battery level
<fjh> suggest adding note that says that geolocation is included as use case to better understand generic model but does not imply that standard work will move the Geolocation WG or to imply that the standard will be changed at this time.
fjh: so this document is not just text, it also has working code
tobie: indeed; there are also separate links to each app
... I'm not convinced yet this is the best format for the end document, but it is good way to present this right now
... I then spent a lot of time on devising an app for head tracking based on device orientation api
... it proved to be very complicated
... I found an interesting paper from occulus that might help; will give another go at it next week
... head tracking is one of the most cross-sensors type of app you can do in an app right now
<fjh> side comment - not sure I like privacy invasive technologies, head tracking might be one of those
tobie: also spent time on device orientation
... I'm looking for a couple of extra use cases that touch on other aspects beyond these
... I'm hoping to have something ready to be published as a FPWD for our next call
fjh: some of our existing work on proximity or ambient light could be added
tobie: right; I'm not as familiar with these but I can take a look
dom: so FPWD 2 weeks from now - do you think we would publish it with or without the live apps?
tobie: I don't know; I think it's cool to have them in, but have no strong opinions
fjh: if we have them in, there might be issues with the publication process
dom: I'll need to look ahead of time to see if we want them in or not
tobie: another approach would be to have screenshots instead of live apps
anssi: yes, with links to the demo apps
... also, we should add more code snippets to contrast the approaches
tobie: yes, that's the goal: more code, explanations
... I'm happy to replace live apps with screenshots and links
fjh: are we talking about being ready for FPWD two weeks from now?
tobie: yes
anssi: sounds like a plan!
[amazing agreement all over]
tobie: my goal is to use the use cases to come to agreement as to what works and what doesn't
... that's the main issue right now to move forward
... the output of the use cases work will be direct input to the generic sensor api work
... my current hope is to get to FPWD-ready for the API 4 weeks from now
... that might be optimistic, but I'll use that as a target
<fjh> status - https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/att-0000/00-part
<fjh> (from https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0000.html)
fjh: not aware of news on that one
Andrey: we updated the spec to move the wake lock request attribute from document to the Screen interface
... the implementation of the wake lock api has landed in Blink
... and the Chromium part is waiting for review
fjh: what should be our next steps?
andrey: we should update the WD to reflect the editors draft
fjh: can we use the simplified publication process?
dom: yes; we could even do that automatically
andrey: that'd be good
<fjh> ACTION: dom to update current WD of Wake Lock and set it up so WD is updated automatically when ED updated [recorded in http://www.w3.org/2015/09/03-dap-minutes.html#action01]
<trackbot> Created ACTION-738 - Update current wd of wake lock and set it up so wd is updated automatically when ed updated [on Dominique Hazaël-Massieux - due 2015-09-10].
dom: ok, I'll look into both publishing an update and set up the automation
<fjh> fjh: how are we notified about updates to WD
dom: I'll look into it
<fjh> dom: home page news should be updated first time
<fjh> no news
<fjh> [removed mistaken paste of action list]
<fjh> Anssi please review your and Ziquiang actions and close those that you can.
<fjh> Gir please review your action and close if done
<fjh> see https://www.w3.org/2009/dap/track/actions/open
<fjh> ACTION-735?
<trackbot> ACTION-735 -- Anssi Kostiainen to Create editor drafts for ambient light and proximity indicating new approach toward generic sensor api, also drafts for publication to tr space -- due 2015-07-02 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/735
<fjh> close ACTION-735
<trackbot> Closed ACTION-735.
<fjh> ACTION-736?
<trackbot> ACTION-736 -- Frederick Hirsch to Send cfc for wd publication for ambient light and proximity once drafts available -- due 2015-07-02 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/736
<fjh> close ACTION-736
<trackbot> Closed ACTION-736.
<fjh> Plan is to have updated Generic Sensor API Use Cases document ready before call in next two weeks, to discuss and then publish FPWD
<fjh> Plan is also to publish updated WD of Wake Lock API and to arrange automatic WD updates when ED updated.
<fjh> Dom to look into how WG is notified when automatic WD updates occur.
<fjh> Thanks to everyone for productive call, especially Tobie for preparing generic sensor use cases, Anssi for WD publications, Dom for scribing!