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

# Device APIs Working Group Teleconference

## 11 Jun 2015

See also: [IRC log][3]

## Attendees

Present

    Frederick_Hirsch, Mats_Wichmann, Anssi_Kostiainen, Tobie_Langel,
Giri_Mandyam, Rick_Waldron

Regrets

    Dominique_Hazael-Massieux

Chair

    Frederick_Hirsch

Scribe

    fjh

## Contents

  * [Topics][4]

    1. [Welcome, scribe selection, agenda review, announcements][5]

    2. [Minutes approval][6]

    3. [Generic Sensor API][7]

    4. [Adjourn][8]

  * [Summary of Action Items][9]

* * *

<trackbot> Date: 11 June 2015

<scribe> Agenda: [https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/0066.html][10]

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

fjh: WebEx best practices:
[https://www.w3.org/2006/tools/wiki/WebExBestPractices][11]

... Using WebEx for first time in this group

<scribe> ScribeNick: fjh

Feedback on /TR styles requested [https://lists.w3.org/Archives/Public/public-
device-apis/2015Apr/0036.html][12]

fjh: I will send a message about the questionnaire re styles to the list,
please review

... please let me know if we use any other authoring tools besides ReSpec, or
if any special CSS is needed

### Minutes approval

**RESOLUTION: Minutes from14 May 2015 are
approved,[https://lists.w3.org/Archives/Public/public-device-
apis/2015May/att-0051/minutes-2015-05-14.html][13]**

### Generic Sensor API

fjh: Generic Sensor API editors draft [http://w3c.github.io/sensors/][14]

issues list: [https://github.com/w3c/sensors/issues/][15]

fjh: tobie to review draft

tobie: need to add use cases section 2, may want to move to separate document

... rick created list of use case

<tobie> [https://github.com/w3c/sensors/issues/21#issuecomment-108081529][16]

tobie: section 3, security and privacy

... will go through material in different sensor specs, copy and paste generic
ones here

... also issue 14 priviiedged context

fjh: issue is whether HTTPS should be required for sensor access not

anssik: see what best practice is

tobie: issue 20 re async permissioning

... need to write text, will move this

... section 4 dependencies, only one issue

... goal is compatible for platforms that do not have DOM

... EventTarget is defined in and part of DOM

... but seems we need EventTarget

... other solutions like observable or event emitters will take too long to
get specified and implemented

gmandyam: considering upgrade to geolocation to use generic sensor api, but
EventTarget makes no sense in that context

tobie: why doesn't make sense

gmandyam: don't need it, works fine for apps not running in browser

tobie: not sure what you suggest, promises

gmandyam: yes

tobie: promises and observables are valuable for some cases

... cannot make system using promises and build event model on it

... looking for proper lower common denominator, hence need event based system

gmandyam: certain sensor interfaces work without EventTarget today shouldn't
use generic sensor API?

... need to go case by case to see where it is appropriate

tobie: want consistency

<scribe> **ACTION:** gmandyam to discuss generic sensor API and use of
EventTarget in Geolocation WG to summarize issues to DAP [recorded in
[http://www.w3.org/2015/06/11-dap-minutes.html#action01][17]]

<trackbot> Created ACTION-733 - Discuss generic sensor api and use of
eventtarget in geolocation wg to summarize issues to dap [on Giridhar Mandyam
- due 2015-06-18].

<tobie> [https://github.com/w3c/sensors/issues/21][18]

ACTION-733: relate to existing [https://github.com/w3c/sensors/issues/21][18]

<trackbot> Notes added to ACTION-733 Discuss generic sensor api and use of
eventtarget in geolocation wg to summarize issues to dap.

tobie: section 5 API, started with Rick's proposal

... close to implementation, need to fix WebIDL

... draft notes issue 8, [https://github.com/w3c/sensors/issues/8][19]

<tobie> [http://tobie.github.io/sensors/][20]

tobie: looking at new version

... question is of discovery for sensors, e.g. for proximity, not necessarily
geolocation

[http://tobie.github.io/sensors/#the-sensors-interface][21]

scribe: tied to performance issues

... need to keep sensors out of critical path, e.g not during page load

... service worker API has API to look for clients of service worker

... mimic , treat sensors as the client, sensors are of the page

... concrete sensor implementations would inherit from Sensors in section 5.1

... page is like service worker

<tobie> [http://tobie.github.io/sensors/#the-sensor-interface][22]

scribe: identifier is opaque, connects to hardware, optional, useful when
single sensor

... see example 1, matchAll

... e.g. get array of sensors for proximity rear

... do not need to subclass sensor observer

gmandyam: our implementation of geofencing, frequency is not static, depends
on distance from fence

... how is this handled

tobie: open issue for that

gmandyam: what is expected behavior

tobie: we have to figure it out

... also open issue for geofencing

<tobie> [https://github.com/w3c/sensors/issues/23][23]

tobie: that is issue for frequency

<tobie> [https://github.com/w3c/sensors/issues/15][24] for geofencing

tobie: no specific issue for geofencing, but mentioned in the following issue

fjh: use of 'rear' is example of issue that came up in HTML Media Capture, how
to define these strings, know what they mean etc. sounds like repeat of what
was in that work

gmandyam: yes that issue came up

<tobie> [https://github.com/w3c/sensors/issues/26][25]

tobie: we need name

... under debate but tentative conclusion is that how to differentiate sensors
of a certain type are sensor type specific

... proximity would be location on device

... temperature would be inside or outside

... so these definitions would not generic

... don't want to deep dive

fjh: agreed, suggest we make this for the concrete sensor specs

tobie: sensor observer is very similar to what was called Sensor in previous
editors draft

... emits specific events

... can set desired frequency of updates, threshholds

... no event if threshhold not met

... batch support is included

... have SensorReading interface

... update to Rick's proposal

fjh: this is metadata about a sensor reading

tobie: yes

fjh: so this could apply for each event

tobie: remember events are polled effectively

... multiple readers at different frequencies, so applciation has to figure
out frequency needed to meet requirements for different sensor objects

... consideration for games

fjh: fusion is not visible to generic sensor api, right

tobie: developer gets one value, looks like one sensor, opaque

... could also have other sensors visible

fjh: does not impact API

tobie: right, could flag it but not necessary

... discussion in issue 24 is lower level primitives

[http://tobie.github.io/sensors/#issue-24][26]

tobie: might be application to ardiuno or web of things

... need better understanding, so cannot make it concrete

fjh: does that need to be in v1

tobie: not in FPWD but don't want to lock ourselves out prematurely

... extensibiilty section

... need to show how to build spec based on generic sensor API, give examples
in this section

... similar to service worker API

[http://www.w3.org/TR/service-workers/][27]

scribe: may need to update permissions spec to add name for sensors, could be
tedious and error-prone

... if user agent implements permissions API and not temperature sensor, would
still have those permissions or require a manual edit

... better would be partial enumerables

... trying to get others to agree

... prefer register in concrete implementation specification

fjh: next steps?

tobie: need Rick to review and agree to changes

fjh: update editors draft, share on list, agree to FPWD

... do not need a perfect draft to publish

tobie: want also to turn issues into spec content

fjh: Much thanks to Tobie for walking us through the Generic Sensor API
document and issues and all for productive meeting.

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** gmandyam to discuss generic sensor API and use of
EventTarget in Geolocation WG to summarize issues to DAP [recorded in
[http://www.w3.org/2015/06/11-dap-minutes.html#action01][17]]


[End of minutes]

* * *

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

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

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

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

   [3]: http://www.w3.org/2015/06/11-dap-irc

   [4]: #agenda

   [5]: #item01

   [6]: #item02

   [7]: #item03

   [8]: #item04

   [9]: #ActionSummary

   [10]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Jun/0066.html

   [11]: https://www.w3.org/2006/tools/wiki/WebExBestPractices

   [12]: https://lists.w3.org/Archives/Public/public-device-
apis/2015Apr/0036.html

   [13]: https://lists.w3.org/Archives/Public/public-device-
apis/2015May/att-0051/minutes-2015-05-14.html

   [14]: http://w3c.github.io/sensors/

   [15]: https://github.com/w3c/sensors/issues/

   [16]: https://github.com/w3c/sensors/issues/21#issuecomment-108081529

   [17]: http://www.w3.org/2015/06/11-dap-minutes.html#action01

   [18]: https://github.com/w3c/sensors/issues/21

   [19]: https://github.com/w3c/sensors/issues/8

   [20]: http://tobie.github.io/sensors/

   [21]: http://tobie.github.io/sensors/#the-sensors-interface

   [22]: http://tobie.github.io/sensors/#the-sensor-interface

   [23]: https://github.com/w3c/sensors/issues/23

   [24]: https://github.com/w3c/sensors/issues/15

   [25]: https://github.com/w3c/sensors/issues/26

   [26]: http://tobie.github.io/sensors/#issue-24

   [27]: http://www.w3.org/TR/service-workers/

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

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