See also: IRC log
RESOLUTION: Minutes from March 3 2016 are approved https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0017.html
<anssik> migrated the spec from Hg to Git: https://github.com/w3c/battery -- now accepting PRs!
Tobie: I brought up two weeks ago
a question with regard to whether the sensor-poll starting
should be split away from creating a new sensor instance
... which generated a useful discussion
... the split-off helped me make more sense of the intricacies
in this space
... I completely rebuilt the polyfill I have to be as close as
possible to spec language, and am now turning that polyfill
into spec language
... and consulting people on some of the low-level aspects of
the platform
... I'm really liking where this is leading
... a much more precise description with fewer surprises
... but it is taking more time than I had hoped
... I was hoping to be done today, but that won't happen; I
still need to deal with some corner cases in error handling and
time outs
Anssi: when can we publish?
Tobie: I chatted with Dom today
about this
... we can publish as any time
Dom: indeed, via echidna we can publish despite the starting moratorium
tobie: some interesting points
emerging today
... now that we have a start method to start polling the
sensor
... I kind of like that the state moves from activated to
active based on the first reading of the sensor
... the question arises when there is an error, what does that
mean? it's harder problem than I expected
... e.g. if the underlying hardware sends an error, is it a
fatal error or not?
... AnneVK suggested to wait until we have implementation
feedback on the
... it could be sensor specific
Dom: I would guess it is indeed sensor-specific; it probably also depends on the error types as well
tobie: how does that relate to our promise-based flow?
dom: if the error means that you can't read from the sensor, the promise should be rejected
tobie: OK, I could see how that would integrate with the algorithm: a fatal error reject the promises, other errors are emitted as error events
dom: might be confusing to have both error events and promise rejection
tobie: yeah, but you might need it e.g. if the sensors can't keep up with the requested frequency
dom: interesting use case; not
clear if there are many such cases or some specific ones that
we can put into the generic spec
... we can probably tackle fatal errors as a starting point,
and see if we need reporting for other type of errors
tobie: sounds good, will look at
that approach
... I've opened a few other issues on which I would want
feedback
... AnneVK suggested that one of the issues should wait for
cancelable promises, which sounds reasonable
... a recent change in DOM on hires timestamp will simplify our
spec
... will try to push for a draft tomorrow
Anssi: I need to update the spec based on the privacy discussion
Andrey: I've reviewed the spec
against the privacy & security questionnaire
... we identified the need to add a privacy & security
section to the spec