Device APIs Working Group Teleconference

11 Jun 2015

See also: IRC log


Frederick_Hirsch, Mats_Wichmann, Anssi_Kostiainen, Tobie_Langel, Giri_Mandyam, Rick_Waldron


<trackbot> Date: 11 June 2015

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

Welcome, scribe selection, agenda review, announcements

fjh: WebEx best practices: https://www.w3.org/2006/tools/wiki/WebExBestPractices
... 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

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

Generic Sensor API

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

issues list: https://github.com/w3c/sensors/issues/

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

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]

<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

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

<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

<tobie> http://tobie.github.io/sensors/

tobie: looking at new version
... question is of discovery for sensors, e.g. for proximity, not necessarily geolocation


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

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

tobie: that is issue for frequency

<tobie> https://github.com/w3c/sensors/issues/15 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

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


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


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.


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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $