See also: IRC log
<trackbot> Date: 11 June 2015
WebEx best practices: https://www.w3.org/2006/tools/wiki/WebExBestPractices
<mats> typically opens 5mins before
<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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/WebE /WebEx / Succeeded: s/telling me 5mins to go// Succeeded: s/<pointless moan>have to use aging windows machine for webex, their java code hates my linux boxes// Succeeded: s/updates/Generic Sensor API editors draft/ Succeeded: s/giri/gmandyam/g Succeeded: s/Whoops// Succeeded: s/ ,/,/ Succeeded: s/step/steps?/ Succeeded: s/Adjour/Adjourn/ Found ScribeNick: fjh Inferring Scribes: fjh Present: Frederick_Hirsch Mats_Wichmann Anssi_Kostiainen Tobie_Langel Giri_Mandyam Rick_Waldron Regrets: Dominique_Hazael-Massieux Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0066.html Found Date: 11 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/11-dap-minutes.html People with action items: gmandyam[End of scribe.perl diagnostic output]