See also: IRC log
<scribe> ScribeNick: fjh
FPWD of Generic Sensor API published, 15 October, see http://www.w3.org/TR/generic-sensor/
Approve minutes from 15 Oct 2015
proposed RESOLUTION: Minutes from 15 Oct 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/att-0037/minutes-2015-10-15.html
RESOLUTION: Minutes from 15 Oct 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Oct/att-0037/minutes-2015-10-15.html
fjh: change to Normative text, so can return to another CR under the new process
... Will do 1 week CfC for return to CR
dom: transition request needed but likely no call needed
Minutes from F2F ad hoc session, http://www.w3.org/2015/10/27-dap-minutes.html
Minutes from breakout http://www.w3.org/2015/10/28-dap-minutes.html
fjh: who is Riju
tobie: working on ambient light with generic sensor API, at Intel
fjh: PresentationAvailability sounded interesting
tobie: quick summary, Dom and Giri were there
... well-received
... high quality conversations
... questions related to key area of spec that needed work, confirming areas to work on
... agreement that spec is at right level and agreement to defer discovery since it is complex, no good use cases shipping today for that
... likely related to work on bluetooth and IoT
... also talked to automotive group, they also joined ad hoc meeting
... gave short presentation for IoT group, which seems at a more theoretical point right now
... I2C and GPIO was presented in plenary
... key takeaways - doing right thing and that there is interest
fjh: asking about timing
tobie: riju on holiday from 6 Dec to january, but has started working on the WebIDL now
... expecting to have major part of that set before holiday, then work on implementation in Jan, goal of late Q1
... should be able to get implementation experience
fjh: and your plans on issues, how does that fit?
tobie: either listen for change or get entire stream of data, two alternatives
... ambient light is 1st
... using threshholds
... stream of data, device orientation would give us this, but no implementation in place right now
... could be issue for defining spec
fjh: is fusion related
tobie: the more the fusion the more likely 1st case but still need to consider high performance cases
... hard to split work
fjh: would like to understand the changes to the spec and when we should publish again
tobie: thinking about what we can take out of spec , and will work soon on some clarifications
... reading algorithm will be difficult without tackling device orientation
... will continue on what can be done, noting issues that remain. Experience from Riju should help
... can underspecify part of algorithm, let device orientation specify it, or have another level of the spec later once we have implementer feedback
gmandyam: device orientation could have LC based on some changes, so should be able to wrap up the spec, that should enable working on new version based on generic sensor API
fjh: any other ways people in group can help with this work
tobie: feedback on algorithms after I do update will be helpful
... working to get this for Jan if I can, not sure of personal availability
fjh: are TAG members aware of this work, should we share with them
tobie: should send to TAG review
... ok on security side, concerned about privacy side
... API design aspect relates to TAG
fjh: probably early, wait for Jan revision with implementation experience
... agree to reference fingerprinting document
tobie: more like guidance
fjh: can ask PING later for review
tobie: automotive concerned about timeline
<tobie> https://github.com/w3c/automotive/issues/72
tobie: they seem to have similar issues to Generic Sensor API, e.g frequency of sensor polling, what if asking for frequency higher than sensor can handle
... will depend on maturity of our spec, other specs will have same problem
... expect it to be similar for IoT group
... timing may work out naturally, once other groups realize the issues are difficult
fjh: anything else useful to discuss today?
tobie: the spec will describe how to read data from a local sensor; how will Web of Things relate?
... not sure how to handle at spec level
... do we need subclass of Generic Sensor that is local sensor
fjh: good to create an issue; will depend on what Web of Things becomes, need to coordinate
tobie: looks like that might happen later
... work right now is on protocol handshakes etc
... concern is whether we should consider local and remote sensors the same way
fjh: could have generic sensor spec and a different spec on how to share over the network
... would be good to avoid dependency and have a separate spec for remote access, would simplify etc
tobie: agree, should defer until we have a well-defined issue
fjh: automotive will have this issue
tobie: yes, but they aren't implementing that yet
dom: under W3C management review, have small set of pull requests, plan is to finalize management review, share pull requests with group then start formal AC review
dom: bluetooth and NFC likely to become WGs later this year, similarity to questions on privacy and security
fjh: Please note that next meeting is 3 Dec then after a holiday break we have meeting 7 January
... see http://www.w3.org/2009/dap/minutes.html
none