See also: IRC log
<trackbot> Date: 11 June 2015
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0066.html
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
RESOLUTION: Minutes from14 May 2015 are approved,https://lists.w3.org/Archives/Public/public-device-apis/2015May/att-0051/minutes-2015-05-14.html
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
http://tobie.github.io/sensors/#the-sensors-interface
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
http://tobie.github.io/sensors/#issue-24
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/
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.