[minutes] DAP Distributed Meeting 17 March 2016

The draft minutes of our teleconference today are available at:
https://www.w3.org/2016/03/17-dap-minutes.html

and copied as text below.

Dom


                Device APIs Working Group Teleconference

17 Mar 2016

   [2]Agenda

      [2]
https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0052.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/03/17-dap-irc

Attendees

   Present
          Tobie_Langel, Dom, Anssi_Kostiainen, Andrey_Logvinov

   Regrets
          Frederick_Hirsch

   Chair
          Dom

   Scribe
          dom

Contents

     * [4]Topics
         1. [5]Minutes approval
         2. [6]Battery Status
         3. [7]Generic Sensor API
         4. [8]Vibration API
         5. [9]WakeLock API
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

Minutes approval

   RESOLUTION: Minutes from March 3 2016 are approved
   [12]https://lists.w3.org/Archives/Public/public-device-apis/201
   6Mar/0017.html

     [12]
https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0017.html

Battery Status

   <anssik> migrated the spec from Hg to Git:
   [13]https://github.com/w3c/battery -- now accepting PRs!

     [13] https://github.com/w3c/battery

Generic Sensor API

   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

Vibration API

   Anssi: I need to update the spec based on the privacy
   discussion

WakeLock API

   Andrey: I've reviewed the spec against the privacy & security
   questionnaire
   ... we identified the need to add a privacy & security section
   to the spec

Summary of Action Items

Summary of Resolutions

    1. [14]Minutes from March 3 2016 are approved
       https://lists.w3.org/Archives/Public/public-device-apis/201
       6Mar/0017.html

   [End of minutes]

Received on Thursday, 17 March 2016 14:37:19 UTC