Device APIs Working Group Teleconference -- 13 Nov 2014

<trackbot> Date: 13 November 2014

<fjh_> Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0014.html

<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

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

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

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

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

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

Minutes approval

fjh_: same for Vibration API

<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

<fjh_> RESOLUTION: Minutes from 2 October 2014 are approved

Generic Sensor API: Context, problem statement, goals

<anssik> https://www.w3.org/wiki/TPAC2014/SessionIdeas#Generic_Sensor_API -> 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 -> 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 -> 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

<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 -> Moz bug 1057185

<anssik> http://www.w3.org/2009/dap/track/issues/170 -> 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/ -> 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 -> 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

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

<scribe> scribenick: anssik

UNKNOWN_SPEAKER: that is a problematic spec
... the spec implemented in four browsers
... changes to implementations is hard
... re Geolocation, we're adding Geofencing exposed to ServiceWorkerGlobalScope
... that seems complementary
... 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

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

https://github.com/rwaldron/sensors -> 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

rwaldon: has been working over two yours on johnny-five framework
... it is a Node.js framework that enables easily to write programs that interact with hardware
... started with client and host model
... communication over serial, like Arduino
... turning those things into sensor terminals
... aim to come up with sensors that are as intuitive as possible
... works with platforms that have GPIO etc. interfaces
... centers around creating a generic sensor instance from a sensor constructor that derives its data from the underlying platform
... currently active
... what this means for browsers
... it doesn't make sense to have a dependency on window
... or navigator object
... both of these objects are inppropriate homes for sensors
... effectively these are stand alone constructors that allow creating N number of instances
... for example, I have temperature sensor in my phone
... I should not need to wait for the event to arrive on the window

or navigator

rwaldron: or promise
... I should have a mechanism to command the frequency of the sensor
... including a change event
... agree with tobie that Tim's proposal is very similar to ours (Rick, Tobie, Domenic)
... but our proposal does not have dependency web related concepts such as window, navigator

https://github.com/rwaldron/sensors -> Sensor API Unification Sketch

scribe: device orientation and some others have landed as implementation in browsers
... however, if we make the existing sensor APIs slightly lower-level
... we'd be giving future developers better APIs
... tobie and Domenic have more to say

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

richt: how to enable feature detection?

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

richt: implementers haven't done that in browsers, that is the current problem
... the pushback as been, you'll need to ask the platform to make sure

rwaldron: secondary mechanism, .value would be null if no sensor exists
... a normative requirement for the specification
... 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).

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

mounir: not a use case, marcos had the same comment
... Node.js environment is different in this regard
... 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

tobie: feature detection is worth discussing on the mailing list

<mounir> +1

tobie: would invite richt

rwaldron: not an attempt to push a specific API e.g. johnny-five's design on Web
... 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

mounir: the main difference to Rick's is that when Tim and I looked at how to make a better sensor API
... first, DeviceOrientation can be only accessed through event
... with Rick's proposal you have .value which may or may not return a value
... in Tim's proposal, the value is always a real value
... since it is gated behind a promise
... other details like hanging off of navigator, we could move elsewhere
... such as fooSensor.getXXX

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

mounir: discussed at TPAC, maybe we should be more clever in how we handle frequency

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

mounir: the mail is the canonical public source
... 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

tobie: mounir explained the difference well, one issue re singleton that Tim advocates
... does not work very well
... other issues can be decided, mostly matter of taste
... not really disagreement on key technical questions

mounir: argreed

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

<mounir> Tim's slide deck: https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf

rwaldron: 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

Potential next steps

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

Draft use cases and requirements (consider known issues)

Evaluate the proposals against the requirements

Flesh out the generic sensor API spec

Update the existing concrete sensor API specs to match

Call for volunteers?

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.

mounir: we could have a GH repo, and work these
... working with script-coord@

https://github.com/rwaldron/sensors

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

proposed RESOLUTION: move https://github.com/rwaldron/sensors 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

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

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

Adjourn

<fjh_> s?ready to go to CR, Anssi can you please prepare CR draft with usual checks, including making a diff/Battery ready to go to CR, Anssi can you please prepare CR draft with usual checks, including making a diff/

<fjh_> s///

<fjh_> s/gmandyam:/gmandyam:/

- DRAFT -

Device APIs Working Group Teleconference

13 Nov 2014

Attendees

Contents