[![W3C][1]][2]

# Device APIs Working Group Teleconference

## 13 Nov 2014

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Anssi_Kostiainen, Mats_Wichmann, Tobie_Langel,
Dominique_Hazael-Massieux, Mounir_Lamouri, Rich_Tibbett, Ted_Guild,
Rick_Waldron, Claes_Nilsson, Giri_Mandyam, Christian_Fuhrhop_from_Fraunhofer,
Paul_Boyes, Ryoichi_Kawada

Regrets


Chair

    Frederick_Hirsch,Anssi_Kostiainen

Scribe

    mounir, anssik

## Contents

  * [Topics][5]

    1. [Welcome, agenda review, scribe selection, announcements, status
updates][6]

    2. [Battery API][7]

    3. [Vibration API][8]

    4. [Minutes approval][9]

    5. [Generic Sensor API: Context, problem statement, goals][10]

    6. [Generic Sensor API: Related work in W3C, current status][11]

    7. [Generic Sensor API Proposal review - Sensor API Unification
Sketch][12]

    8. [Generic Sensor API Proposal review - Tim Volodine's proposal][13]

    9. [Generic Sensor API - Summary, Discussion and Next Steps][14]

    10. [Adjourn][15]

  * [Summary of Action Items][16]

* * *

<trackbot> Date: 13 November 2014

<PaulBoyes> Paul Boyes - Co-Chair Automotive BG

<rwaldron> Good morning and afternoon

<dom> scribenick: mounir

mounir: I'm going to describe Tim's proposal

### Welcome, agenda review, scribe selection, announcements, status updates

<fjh> wake lock status - [http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0010.html][17]

<fjh> health care TPAC breakout summary - [http://lists.w3.org/Archives/Public
/public-device-apis/2014Nov/0007.html][18]

fjh: we had a breakout session at TPAC about Health Care Sensor APIs

... there is a lot of interest

... a takeway is that the group thinks there needs to be a horizontal platform
as well as work on verticals , with feedback loops. A starting point discussed
was the web of things interest group.

### Battery API

<fjh> CfC for transitioning and publishing Battery API as CR completed
successfully, [http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0012.html][19]

fjh: Battery ready to go to CR, Anssi can you please prepare CR draft with
usual checks, including making a diff

anssik: will do this

### Vibration API

<fjh> CfC for transitioning and publishing Vibration API as PR completed
successfully, [http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0013.html][20]

fjh: Vibration ready to go to PR, Anssi can you please prepare CR draft with
usual checks, including making a diff

anssik: will do this

### Minutes approval

<fjh> Approve minutes from 2 October 2014

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2014Oct/att-0003/minutes-2014-10-02.html][21]

**RESOLUTION: Minutes from 2 October 2014 are approved**

### Generic Sensor API: Context, problem statement, goals

<fjh> Note - Anssi chaired this portion of the call

<anssik>
[https://www.w3.org/wiki/TPAC2014/SessionIdeas#Generic_Sensor_API][22] -> TPAC
breakout session "Generic Sensor API"

anssik: we meant to talk about generic sensors at TPAC but many folks

... were not present at the TPAC meeting

... we have numerous sensors exposed to the Web platform

... <listing a few>

<anssik> A number of sensors are already exposed to the Web Platform (e.g.
Geolocation, Device Orientation) and new sensors are on their way (e.g.
Ambient Light).

<anssik> Current status of sensor APIs on the Web Platform:

<anssik> [http://www.w3.org/Mobile/mobile-web-app-
state/#Sensors_and_hardware_integration][23] -> W3C Sensors Roadmap

anssik: a good summary can be found in a document dom has been working on

<anssik> Also more experimental work in the pipeline, such as domain-specific
sensors: automotive, health care

anssik: in addition, there is more experimental work in the pipeline

... there is currently no established defined pattern

<anssik> No established design pattern that is a particularly good fit for
sensor APIs on the Web Platform

<anssik> Current sensor APIs on the Web are high-level, abstract away details

<anssik> The Node.js community has defined and implemented lower-level
composable APIs for exposing new sensors

<anssik> [https://github.com/rwaldron/johnny-five#sensors][24] -> johnny-five
Sensors

<anssik> Problem statement

<anssik> Proliferation of sensor APIs on the Web Platform + lack of applicable
design patterns and best practices = suboptimal and inconsistent APIs

<anssik> More specifically

<anssik> New use cases and requirements unaddressed by the current high-level
APIs

<fjh> suboptimal in which way?

<dom> [@@_from_Fraunhofer might be Christian Fuhrhop]

<anssik> New requirements likely cannot be addressed by incremental
improvements (“v2”) due to different level of abstraction -- layered design to
rescue?

<anssik> Lack of consistency leading to web developer ergonomics issues

<Louay_> Webinos project already worked on a spec for Generic Sensor and
Actuator API [http://dev.webinos.org/specifications/api/sensors.html][25]

<anssik> Known issues overview

<anssik> Since we now have web developer feedback and validation we can do
data-driven API design

<anssik> Known issues shared with all sensor APIs that define a new DOM event
type (DeviceOrientationEvent, DeviceMotionEvent, DeviceLightEvent,
DeviceProximityEvent etc.):

<anssik> 1) Unable to retrieve a sensor reading at any time

<anssik> [https://bugzil.la/1057185][26] -> Moz bug 1057185

<anssik> [http://www.w3.org/2009/dap/track/issues/170][27] -> W3C spec issue
re Moz bug 1057185

<anssik> gmandyam: issue 1) not affecting Geolocation API

<fjh> gmandyam notes it is an API sensor design issue, not a motivation for
generic sensor

<anssik> 2) Limited to a single sensor of each type

<anssik> [https://extensiblewebreportcard.org/][28] -> issue noted by TAG, see
“Sensors”

<gmandyam> Geolocation has getCurrentPosition, and watchPosition is supposed
to return a Position object if successfully invoked. Mozilla bug 1057185 is
not a generic sensor API problem, but one due to design choices of Ambient
Light

<anssik> 3) Sensors in loop-based situations (use cases: games, accelerometer-
based scrolling, augmented reality)

<anssik> [https://github.com/rwaldron/sensors/issues/5][29] -> Provide a way
of tying sensor requests to animation frames

<fjh> due to events?

<Zakim> tobie, you wanted to mention slowness of implementing and deploying
new sensor apis (ties to #2 above)

<fjh> anssik says yes

<anssik> tobie: takes a lot of time to introduce a new sensor

<anssik> ... implement in browsers

<fjh> tobie notes that time to market for new sensors impacted by not having
generic sensor api, due to more time for specs, etc

mounir: I think experimentation is slightly out of topic, it's not specific to
sensors

<anssik> 4) Sensor frequency not developer configurable

mounir: but is more generic to the web platform even though it tends

... to be a bigger problem for hardware-related apis

<anssik> 5) Threshold (min/max) not developer configurable

mounir: There are a few ideas around like the api keys proposed

... by Microsoft at TPAC and discussed at BlinkOn and also

... navigator.connect() that has some shared goals

<gmandyam> Tying sensor API's to requestAnimationFrame is one issue. But is a
general sensor API needed that operates like requestAnimationFrame? For
instance, requestSensorData which only invokes the successCallback when the
sensor is ready to provide new data?

<anssik> 6) Dependency on the window object or other web related concepts

<anssik> cannot be exposed to background processing (ServiceWorkerGlobalScope)
or other window-less contexts (e.g. Node.js global)

<gmandyam> Developer requesting sensor frequency may be OK, as long as they
are not mandatory. Implementations may modulate the sensor frequency depending
on the function (e.g. geofencing, where location polling frequency is adjusted
based on distance from virtual geofence)

<anssik> To draw parallels, WHATWG Streams is currently agnostic to the
environment, implementable in the browser and Node.js environments.

<anssik> W3C Streams API extends the WHATWG spec to meet the requirements
specific to the browser environment.

<anssik> Can we do something similar and agree on the right level of
abstraction for a low-level API (“generic sensor API”) that enables high-level
APIs as polyfills?

<fjh> idea of base multi-purpose spec with vertical specific specs above it
might tie into discussion from TPAC health care discussion

<Zakim> fjh, you wanted to ask about testing, progressing generic api

### Generic Sensor API: Related work in W3C, current status

fjh: in DAP, we explicitely decided to do small specifications that can evolve
quickly

<anssik> fjh: how to do testing

fjh: with a generic sensor API, how do you know it does work given that it is
generic?

<fjh> mounir notes could create Note for basis then create specs that are
testable using it

<fjh> DAP work on sensors; see
[http://www.w3.org/2009/dap/wiki/SingleSensorSpecification][30]

mounir: a generic sensor api is meant to be a pattern, not something to
publish, implement and test

<fjh> thanks, that answers the question

<anssik> gmandyam: met at TPAC, richt, Tim attended, we looked at
DeviceOrientation

<anssik> ... that is a problematic spec

<anssik> ... the spec implemented in four browsers

<anssik> ... changes to implementations is hard

<anssik> ... re Geolocation, we're adding Geofencing exposed to
ServiceWorkerGlobalScope

<anssik> ... that seems complementary

<anssik> ... people pointed out at the TPAC why Geolocation WG was separate

<Zakim> tobie, you wanted to comment on polyfilling existing APIs

<gmandyam> Geolocation: the Geo WG met at the recent TPAC and took up the
issues regarding DeviceOrientation: minutes are in
[http://www.w3.org/2014/10/27-28-geolocation-minutes.html][31]

<anssik> tobie: it is important, when designing a generic sensor API, to be
able to polyfill existing APIs

### Generic Sensor API Proposal review - Sensor API Unification Sketch

<fjh> fjh: as long as this does not harm new API design, to the extent
possible

<rwaldron> [https://github.com/rwaldron/sensors][32]

<anssik> [https://github.com/rwaldron/sensors][32] -> Sensor API Unification
Sketch

<gmandyam> Geolocation (cont.): Tim Volodine (Google) presented how
DeviceOrientation can be adapted in the context of a generic Sensor API:
[https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf][33]

<anssik> rwaldon: has been working over two yours on johnny-five framework

<anssik> ... it is a Node.js framework that enables easily to write programs
that interact with hardware

<anssik> ... started with client and host model

<anssik> ... communication over serial, like Arduino

<anssik> ... turning those things into sensor terminals

<anssik> ... aim to come up with sensors that are as intuitive as possible

<anssik> ... works with platforms that have GPIO etc. interfaces

<anssik> ... centers around creating a generic sensor instance from a sensor
constructor that derives its data from the underlying platform

<anssik> ... currently active

<anssik> ... what this means for browsers

<anssik> ... it doesn't make sense to have a dependency on window

<anssik> ... or navigator object

<anssik> ... both of these objects are inppropriate homes for sensors

<anssik> ... effectively these are stand alone constructors that allow
creating N number of instances

<anssik> ... for example, I have temperature sensor in my phone

<anssik> ... I should not need to wait for the event to arrive on the window

<anssik> or navigator

<anssik> rwaldron: or promise

<anssik> ... I should have a mechanism to command the frequency of the sensor

<anssik> ... including a change event

<anssik> ... agree with tobie that Tim's proposal is very similar to ours
(Rick, Tobie, Domenic)

<anssik> ... but our proposal does not have dependency web related concepts
such as window, navigator

<anssik> [https://github.com/rwaldron/sensors][32] -> Sensor API Unification
Sketch

<anssik> ... device orientation and some others have landed as implementation
in browsers

<anssik> ... however, if we make the existing sensor APIs slightly lower-level

<anssik> ... we'd be giving future developers better APIs

<anssik> ... tobie and Domenic have more to say

<Zakim> richt, you wanted to ask if/how this proposal enables feature
detection

<anssik> richt: how to enable feature detection?

<anssik> rwaldron: if a browser support the sensor, the sensor constructor
will exists, otherwise not

<anssik> richt: implementers haven't done that in browsers, that is the
current problem

<anssik> ... the pushback as been, you'll need to ask the platform to make
sure

<anssik> rwaldron: secondary mechanism, .value would be null if no sensor
exists

<anssik> ... a normative requirement for the specification

<anssik> ... we request a promise, of .value does not have a value the sensor
is not supported

<richt> DeviceOrientation feature detection in this model has been a problem
([https://github.com/w3c/deviceorientation/pull/12).][34]

<fjh> rwaldron: cannot have value unless support reading from sensors

<anssik> mounir: not a use case, marcos had the same comment

<anssik> ... Node.js environment is different in this regard

<anssik> mounir: browsers have more constraints than Node.js

<fjh> group notes node.js offers insight but not necessarily the use case

<Zakim> tobie, you wanted to comment on feature detection

<anssik> tobie: feature detection is worth discussing on the mailing list

+1

<anssik> ... would invite richt

<anssik> rwaldron: not an attempt to push a specific API e.g. johnny-five's
design on Web

<anssik> ... just want to share learnings from other context

### Generic Sensor API Proposal review - Tim Volodine's proposal

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2014Sep/0024.html][35]

<anssik> mounir: the main difference to Rick's is that when Tim and I looked
at how to make a better sensor API

<anssik> ... first, DeviceOrientation can be only accessed through event

<anssik> ... with Rick's proposal you have .value which may or may not return
a value

<anssik> ... in Tim's proposal, the value is always a real value

<anssik> ... since it is gated behind a promise

<anssik> ... other details like hanging off of navigator, we could move
elsewhere

<anssik> ... such as fooSensor.getXXX

<fjh> mounir: rejected if not available so not even aware there is no sensor,
might be positive for privacy

<anssik> ... discussed at TPAC, maybe we should be more clever in how we
handle frequency

<anssik> [http://lists.w3.org/Archives/Public/public-device-
apis/2014Sep/0024.html][35]

<anssik> mounir: the mail is the canonical public source

<anssik> ... will look for a better pointer

<gmandyam> I already pasted the link on IRC

<gmandyam> Here is the link to Tim's presentation again:
[https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf][33]

<anssik> tobie: mounir explained the difference well, one issue re singleton
that Tim advocates

<anssik> ... does not work very well

<anssik> ... other issues can be decided, mostly matter of taste

<anssik> ... not really disagreement on key technical questions

<anssik> mounir: argreed

<anssik> rwaldron: I see these as the same, the proposals are doing the same
things

Tim's slide deck: [https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-
sensors.pdf][33]

<anssik> ... our spec works better with a map of active sensors

### Generic Sensor API - Summary, Discussion and Next Steps

<fjh> fjh: what is next step, create a draft on the list?

<fjh> general response is to continue on list

<anssik> Potential next steps

<anssik> Document known issues with existing APIs (currently spread across
issue trackers)

<anssik> Draft use cases and requirements (consider known issues)

<anssik> Evaluate the proposals against the requirements

<anssik> Flesh out the generic sensor API spec

<anssik> Update the existing concrete sensor API specs to match

<anssik> Call for volunteers?

<anssik> mounir: we could do this WebMob IG way

<rwaldron> The item noted as a difference between "Sensor API Unification
Sketch" (SAUS) and Tim's proposal is actually not a difference at all. Both
versions initialize as null and would result in receiving the initial value
payload at the same time. The real difference is that Tim's proposal doesn't
allow user code to initialize a sensor object and do something with the
reference (such as putting it into some sensor registry Map), whereas SAUS
gives you the instance

<rwaldron> immediately, which allows the reference to be used in interesting
ways before the initial payload is delivered.

<anssik> ... we could have a GH repo, and work these

<anssik> ... working with script-coord@

<anssik> [https://github.com/rwaldron/sensors][32]

<tobie> I can coordinate with Rick + dom for that.

<anssik> proposed RESOLUTION: move [https://github.com/rwaldron/sensors][32]
under "w3c" org and work from there, Anssi to check with W3C Team contact Dom

<fjh> create new git work area to develop the note

<anssik> proposed RESOLUTION: create a GH repo where we can continue to work,
Anssi to check with W3C Team contact Dom

<scribe> scribenick: anssik

**RESOLUTION: create a GH repo where we can continue the work, Anssi to check
with W3C Team contact Dom**

### Adjourn

## Summary of Action Items

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][36] version 1.135 ([CVS
log][37])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0014.html

   [4]: http://www.w3.org/2014/11/13-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #ActionSummary

   [17]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0010.html

   [18]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0007.html

   [19]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0012.html

   [20]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Nov/0013.html

   [21]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Oct/att-0003/minutes-2014-10-02.html

   [22]: https://www.w3.org/wiki/TPAC2014/SessionIdeas#Generic_Sensor_API

   [23]: http://www.w3.org/Mobile/mobile-web-app-
state/#Sensors_and_hardware_integration

   [24]: https://github.com/rwaldron/johnny-five#sensors

   [25]: http://dev.webinos.org/specifications/api/sensors.html

   [26]: https://bugzil.la/1057185

   [27]: http://www.w3.org/2009/dap/track/issues/170

   [28]: https://extensiblewebreportcard.org/

   [29]: https://github.com/rwaldron/sensors/issues/5

   [30]: http://www.w3.org/2009/dap/wiki/SingleSensorSpecification

   [31]: http://www.w3.org/2014/10/27-28-geolocation-minutes.html

   [32]: https://github.com/rwaldron/sensors

   [33]: https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf

   [34]: https://github.com/w3c/deviceorientation/pull/12).

   [35]: http://lists.w3.org/Archives/Public/public-device-
apis/2014Sep/0024.html

   [36]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [37]: http://dev.w3.org/cvsweb/2002/scribe/