See also: IRC log
<scribe> ScribeNick: dom
<fjh> dom: have activated github digest notifications into list, nobody needs to do anything special
<fjh> Approve minutes from 15 December 2016
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Dec/att-0007/minutes-2016-12-15.html
<fjh> proposed RESOLUTION: Minutes from 15 December 2016 are approved
RESOLUTION: Minutes from 15 December 2016 are approved https://lists.w3.org/Archives/Public/public-device-apis/2016Dec/att-0007/minutes-2016-12-15.html
<fjh> CfC to shelve completed - https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0000.html
Frederick: CfC completed, WG Note published, home page updated
Frederick: probably nothing worth discussing without Tobie on the call
... Tobie was planning to do a bunch of work based on the garbage collection issue that was raised
Dom: reviewed
Andrey: and merged
... I have started the implementation of the new API in Chromium
Dom: should we ping the TAG to let them know about the refactoring of the API
Andrey: yes
<fjh> https://w3c.github.io/wake-lock/
Dom: I'll ping them, putting Andrey in the loop
<scribe> ACTION: Dom to let the TAG know about the updated Wake Lock spec [recorded in http://www.w3.org/2017/01/12-dap-minutes.html#action01]
<trackbot> Created ACTION-783 - Let the tag know about the updated wake lock spec [on Dominique Hazaël-Massieux - due 2017-01-19].
Andrey: note that ReSpec has been updated, raising new warnings
Dom: indeed; my other WG has been affected too; a bit annoyed by that change
... but can help fixing bugs if anybody needs help
close ACTION-782
<trackbot> Closed ACTION-782.
Tobie: had a long meeting with the Intel implementors on Tuesday
... goal is to release generic sensor, ambient light and the motion sensors in the main Chrome version pretty soon
... which means I need fixing lots of stuff pretty quickly
... we identified 4 areas that need work:
... - garbage collection (which is leading to large API change, hopefully by tomorrow)
... - open privacy & security issues that need non-normative additions (no clear timeframe)
... - the permission model - but the editor has been on paternity leave, and there are still a lot of fluctuations in it
... right now you have to add permissions to the main permission api, which isn't great, but not sure we can avoid it for now
... - reporting mode issue which we discussed last time
... there are disagreements and lack of clarity on whether there are or will be "push" sensors in shipping devices
... which might affect whether or not and when developers can set the reporting mode
... also, there are platforms that make it difficult or impossible to expose sensors properly to developers
... hoping to tackle those next week, with lots of write-ups
... Google Devrel has started to make quite a bit of promotion on generic sensor api
... want to talk with him to see if he can connect me with developers that have strong requirements around this
... but I first need a solid write up
Frederick: not sure I fully understand the push issue
... is that a sensor changing under you in how it reports its data?
Tobie: there are a number of aspects
... I wrote the spec with the goal of shipping a level 1 with a framework on which we can build in the future
... and that provides an equivalent feature set to existing sensors API (a la device orientation)
... and fixes the known issues of these APIs
... one of these issues is to be able to read sensor data immediately, without having to wait for its value to have an initial change
... and another was to allow setting the polling frequency
... Now that led me to design an API with 2 reporting models: periodic - for sensors that support it, you'll get back data at the said frequency; ua-dependent - let implementors provide data as it sees fits, typically only when data changes
... the latter allowing important battery saving
Frederick: I'm hearing not all sensors / use cases are the same, and thus need different APIs
... how can we manage this under a single API?
Tobie: the polling frequency use cases are strictly useful for the motion sensor API
Frederick: so the generic sensor supports both, and concrete sensors pick one?
Tobie: more specifically, concrete sensors need to specify whether they support periodic or not
... maybe this could be exposed more distinctly than a simple parameter - will need to think about it
... in any case, I'm getting feedback that all sensors should allow poll-based reporting
... my issue is that this prevents battery optimizations
... I guess "frequency" could be a hint rather than a setting
... if a hint, it would be down to developers to determine if that provides the needed accuracy for their use case
... In general, the more we can make decisions at the level of the generic sensor, the better both writing concrete specs and keeping them consistent
... Another point worth mentioning: there is a new whatwg spec - infra - that specifies a number of abstract data structures
<tobie> https://infra.spec.whatwg.org/
Tobie: it makes it easier to spec things consistently
... I'm relying on a bunch of things specified in there
... (ordered lists, ordered maps)
... it helps with using a consistent terminology and algorithms
Frederick: so priority is garbage collection right?
tobie: yes
... bringing a really large spec change
... then it will be much easier to close a number of smaller issues
Frederick: how are we doing on the security/privacy sections? we had volunteers to help?
Tobie: yes, so far, it's mostly about threat models which will lead to non-normative additions to the specs
... e.g. keylogging via accelerometer
Frederick: how can others help you?
Tobie: I need to get back into the spec now
... I'll then write up executive summaries of known issues to look for solid feedback from TAG, developers
... similar to the feedback we got on garbage collection
<fjh> ACTION-780?
<trackbot> ACTION-780 -- Dominique Hazaël-Massieux to Accept pull request for ambient light -- due 2016-12-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/780
close ACTION-780
<trackbot> Closed ACTION-780.