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.
<fjh> s/rrsagent, gnerate minues//
<fjh> s’s/rrsagent, gnerate minues//‘’
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/atm/now/ Succeeded: s/GC/garbage collection/ FAILED: s/rrsagent, gnerate minues// Found ScribeNick: dom Inferring Scribes: dom Present: Frederick_Hirsch Andrey_Logvinov Dominique_Hazael-Massieux Wanming_Lin Tobie_Langel Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017Jan/0001.html Found Date: 12 Jan 2017 Guessing minutes URL: http://www.w3.org/2017/01/12-dap-minutes.html People with action items: dom[End of scribe.perl diagnostic output]