See also: IRC log
<trackbot> Date: 03 September 2015
<Dapeng_Liu> May I ask what is the meeting password?
<Dapeng_Liu> thanks
<fjh> ScribeNick: fjh
the /TR style sheet response sent: https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0021.html
fjh: I submitted the style sheet response
TPAC reminder (no DAP F2F): http://www.w3.org/2015/10/TPAC/
fjh: who will be leading breakout session at TPAC
anssik: I will be there, expect Tobie as well, Giri you might wish to join
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
<anssik> +1
dom: geolocation WG had no objection to DAP taking over device orientation so we should add to charter
+1
<anssik> +1
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)
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 testin
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
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
There is also a pull request regarding licensing
https://lists.w3.org/Archives/Public/public-device-apis/2015Jul/0003.html
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
Draft updated for privacy considerations: https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0011.html
fjh: 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> 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> fjh: if we have them in, there might be issues with the publication process
<fjh> 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
<fjh> tobie: could replace with screen shots if needed, then link to demo apps on github
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> ACTION-723: Zhiqiang Zhang to Add test for user denial of captured file leading to no capture
<trackbot> Notes added to ACTION-723 Add test for user denial of captured file leading to no capture.
<fjh> ACTION-727: Anssi Kostiainen to Contact tim and boris re joining dap
<trackbot> Notes added to ACTION-727 Contact tim and boris re joining dap.
<fjh> ACTION-729: Zhiqiang Zhang to Update test case to clarify manual testing and to run tests and update results related to action-723
<trackbot> Notes added to ACTION-729 Update test case to clarify manual testing and to run tests and update results related to action-723.
<fjh> ACTION-730: Zhiqiang Zhang to Update the battery test suite to match latest battery spec (coordinating with marcos)
<trackbot> Notes added to ACTION-730 Update the battery test suite to match latest battery spec (coordinating with marcos).
<fjh> ACTION-731: Dominique Hazael-Massieux to Review html media capture tests
<trackbot> Notes added to ACTION-731 Review html media capture tests.
<fjh> ACTION-732: Anssi Kostiainen to Review html media capture tests
<trackbot> Notes added to ACTION-732 Review html media capture tests.
<fjh> ACTION-733: Giridhar Mandyam to Discuss generic sensor api and use of eventtarget in geolocation wg to summarize issues to dap
<trackbot> Notes added to ACTION-733 Discuss generic sensor api and use of eventtarget in geolocation wg to summarize issues to dap.
<fjh> ACTION-734: Anssi Kostiainen to Contact mozilla and microsoft re interest in implementing html media capture vs shelving
<trackbot> Notes added to ACTION-734 Contact mozilla and microsoft re interest in implementing html media capture vs shelving.
<fjh> 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
<trackbot> Notes added to ACTION-735 Create editor drafts for ambient light and proximity indicating new approach toward generic sensor api, also drafts for publication to tr space.
<fjh> ACTION-736: Frederick Hirsch to Send cfc for wd publication for ambient light and proximity once drafts available
<trackbot> Notes added to ACTION-736 Send cfc for wd publication for ambient light and proximity once drafts available.
<fjh> completed
<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> Thanks Tobie for preparing the generic sensor API use cases draft and presenting it, Anssi for the publication and battery work. Thanks Dom for scribing, thanks everyone! good call.
<fjh> s/Topic: Generic Sensor API$//
<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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Dapend/Dapeng/ Succeeded: s/This is me// Succeeded: s/dialed in via phone// Succeeded: s/TPA/TPAC/ Succeeded: s/compiant/compliant/ Succeeded: s/+1// Succeeded: s/warnng/warning/ Succeeded: s/deviceorientation/device orientation/ FAILED: s/Topic: Generic Sensor API$// Found ScribeNick: fjh Found ScribeNick: dom Inferring Scribes: fjh, dom Scribes: fjh, dom ScribeNicks: fjh, dom Present: Andrey_Logvinov Anssi_Kostiainen Dapeng_Liu Dominique_Hazael-Massieux Frederick_Hirsch Giri_Mandyam Tobie_Langel Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Aug/0021.html Found Date: 03 Sep 2015 Guessing minutes URL: http://www.w3.org/2015/09/03-dap-minutes.html People with action items: dom[End of scribe.perl diagnostic output]