13:38:33 RRSAgent has joined #dap 13:38:33 logging to http://www.w3.org/2015/06/11-dap-irc 13:38:35 RRSAgent, make logs world 13:38:35 Zakim has joined #dap 13:38:37 Zakim, this will be DAP 13:38:37 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 22 minutes 13:38:38 Meeting: Device APIs Working Group Teleconference 13:38:38 Date: 11 June 2015 13:38:58 Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0066.html 13:39:11 fjh has changed the topic to: dap https://lists.w3.org/Archives/Public/public-device-apis/2015Jun/0066.html WebEx password dap 13:39:38 Chair: Frederick_Hirsch 13:39:41 Present+ Frederick_Hirsch 13:39:50 Regrets+ Dominique_Hazael-Massieux 13:40:11 Topic: Welcome, scribe selection, agenda review, announcements 13:40:28 WebE best practices: https://www.w3.org/2006/tools/wiki/WebExBestPractices 13:40:37 s/WebE /WebEx / 13:43:57 anssik has joined #dap 13:45:21 fjh has joined #dap 13:47:39 Present+ Mats_Wichmann 13:48:26 typically opens 5mins before 13:49:37 telling me 5mins to go 13:50:02 have to use aging windows machine for webex, their java code hates my linux boxes 13:50:30 s/telling me 5mins to go// 13:50:37 s/have to use aging windows machine for webex, their java code hates my linux boxes// 13:56:47 Present+ Anssi_Kostiainen 14:00:06 present+ Tobie_Langel 14:03:18 gmandyam has joined #dap 14:06:54 ScribeNick: fjh 14:07:13 Feedback on /TR styles requested https://lists.w3.org/Archives/Public/public-device-apis/2015Apr/0036.html 14:08:25 fjh: I will send a message about the questionnaire re styles to the list, please review 14:09:08 fjh: please let me know if we use any other authoring tools besides ReSpec, or if any special CSS is needed 14:09:23 Topic: Minutes approval 14:09:31 RESOLUTION: Minutes from14 May 2015 are approved,https://lists.w3.org/Archives/Public/public-device-apis/2015May/att-0051/minutes-2015-05-14.html 14:09:41 Topic: Generic Sensor API 14:10:07 fjh: updates http://w3c.github.io/sensors/ 14:10:53 issues list: https://github.com/w3c/sensors/issues/ 14:11:00 fjh: tobie to review draft 14:11:21 s/updates/Generic Sensor API editors draft/ 14:11:46 tobie: need to add use cases section 2, may want to move to separate document 14:12:02 ... rick created list of use case 14:12:56 https://github.com/w3c/sensors/issues/21#issuecomment-108081529 14:13:21 ... section 3, security and privacy 14:13:43 ... will go through material in different sensor specs, copy and paste generic ones here 14:13:53 ... also issue 14 priviiedged context 14:14:33 fjh: issue is whether HTTPS should be required for sensor access not 14:14:43 anssik: see what best practice is 14:14:51 tobie: issue 20 re async permissioning 14:15:04 ... need to write text, will move this 14:15:18 tobie: section 4 dependencies, only one issue 14:15:36 ... goal is compatible for platforms that do not have DOM 14:15:46 ... EventTarget is defined in and part of DOM 14:15:55 ... but seems we need EventTarget 14:16:28 ... other solutions like observable or event emitters will take too long to get specified and implemented 14:17:11 giri: considering upgrade to geolocation to use generic sensor api, but EventTarget makes no sense in that context 14:17:20 tobie: why doesn't make sense 14:17:31 giri: don't need it, works fine for apps not running in browser 14:18:19 Present+ Giri_Mandyam 14:18:27 tobie: not sure what you suggest, promises 14:18:35 giri: yes 14:19:02 tobie: promises and observables are valuable for some cases 14:19:13 s/giri/gmandyam/g 14:19:23 rrsagent, generate minutes 14:19:23 I have made the request to generate http://www.w3.org/2015/06/11-dap-minutes.html fjh 14:19:38 tobie: cannot make system using promises and build event model on it 14:19:54 ... looking for proper lower common denominator, hence need event based system 14:21:18 gmandyam: certain sensor interfaces work without EventTarget today shouldn't use generic sensor API? 14:21:29 ... need to go case by case to see where it is appropriate 14:21:35 tobie: want consistency 14:21:40 q? 14:22:52 rwaldron has joined #dap 14:23:00 present+ Rick_Waldron 14:23:02 Whoops 14:23:14 s/Whoops// 14:24:21 action: gmandyam to discuss generic sensor API and use of EventTarget in Geolocation WG to summarize issues to DAP 14:24:21 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]. 14:25:04 https://github.com/w3c/sensors/issues/21 14:25:14 ACTION-733: relate to existing https://github.com/w3c/sensors/issues/21 14:25:14 Notes added to ACTION-733 Discuss generic sensor api and use of eventtarget in geolocation wg to summarize issues to dap. 14:26:00 tobie: section 5 API, started with Rick's proposal 14:26:41 ... close to implementation , need to fix WebIDL 14:26:48 s/ ,/,/ 14:27:07 ... draft notes issue 8, https://github.com/w3c/sensors/issues/8 14:27:31 http://tobie.github.io/sensors/ 14:27:39 ... looking at new version 14:28:07 ... question is of discovery for sensors, e.g. for proximity, not necessarily geolocation 14:28:27 http://tobie.github.io/sensors/#the-sensors-interface 14:28:33 ... tied to performance issues 14:29:00 ... need to keep sensors out of critical path, e.g not during page load 14:29:31 ... service worker API has API to look for clients of service worker 14:30:33 ... mimic , treat sensors as the client, sensors are of the page 14:31:33 ... concrete sensor implementations would inherit from Sensors in section 5.1 14:31:49 ... page is like service worker 14:31:57 http://tobie.github.io/sensors/#the-sensor-interface 14:32:38 ... identifier is opaque, connects to hardware, optional, useful when single sensor 14:32:40 q+ 14:33:57 ... see example 1, matchAll 14:34:27 ... e.g. get array of sensors for proximity rear 14:34:29 q+ 14:35:06 ... do not need to subclass sensor observer 14:35:08 ack gmandyam 14:35:40 gmandyam: our implementation of geofencing, frequency is not static, depends on distance from fence 14:35:47 ... how is this handled 14:35:58 tobie: open issue for that 14:36:30 gmandyam: what is expected behavior 14:36:34 tobie: we have to figure it out 14:36:42 ... also open issue for geofencing 14:37:49 https://github.com/w3c/sensors/issues/23 14:37:55 ... that is issue for frequency 14:38:21 https://github.com/w3c/sensors/issues/15 for geofencing 14:38:23 ... no specific issue for geofencing, but mentioned in the following issue 14:39:39 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 14:39:46 gmandyam: yes that issue came up 14:39:49 https://github.com/w3c/sensors/issues/26 14:39:55 tobie: we need name 14:40:27 ... under debate but tentative conclusion is that how to differentiate sensors of a certain type are sensor type specific 14:40:41 ... proximity would be location on device 14:40:49 ... temperature would be inside or outside 14:40:58 ... so these definitions would not generic 14:41:52 ... don't want to deep dive 14:42:04 fjh: agreed, suggest we make this for the concrete sensor specs 14:42:17 q? 14:42:20 q- 14:42:42 tobie: sensor observer is very similar to what was called Sensor in previous editors draft 14:42:55 ... emits specific events 14:43:11 ... can set desired frequency of updates, threshholds 14:43:22 ... no event if threshhold not met 14:43:30 ... batch support is included 14:44:27 ... have SensorReading interface 14:44:55 ... update to Rick's proposal 14:45:16 q? 14:45:56 fjh: this is metadata about a sensor reading 14:45:59 tobie: yes 14:46:10 fjh: so this could apply for each event 14:46:22 tobie: remember events are polled effectively 14:46:59 ... multiple readers at different frequencies, so applciation has to figure out frequency needed to meet requirements for different sensor objects 14:47:34 ... consideration for games 14:48:51 fjh: fusion is not visible to generic sensor api, right 14:49:17 tobie: developer gets one value, looks like one sensor, opaque 14:49:48 tobie: could also have other sensors visible 14:49:55 fjh: does not impact API 14:50:05 tobie: right, could flag it but not necessary 14:50:16 q? 14:51:08 tobie: discussion in issue 24 is lower level primitives 14:51:20 http://tobie.github.io/sensors/#issue-24 14:51:35 tobie: might be application to ardiuno or web of things 14:51:51 ... need better understanding, so cannot make it concrete 14:52:02 fjh: does that need to be in v1 14:52:23 tobie: not in FPWD but don't want to lock ourselves out prematurely 14:52:46 ... extensibiilty section 14:53:22 ... need to show how to build spec based on generic sensor API, give examples in this section 14:53:37 ... similar to service worker API 14:54:07 http://www.w3.org/TR/service-workers/ 14:54:49 ... may need to update permissions spec to add name for sensors, could be tedious and error-prone 14:55:33 ... if user agent implements permissions API and not temperature sensor, would still have those permissions or require a manual edit 14:55:34 ... better would be partial enumerables 14:55:48 ... trying to get others to agree 14:56:54 ... prefer register in concrete implementation specification 14:57:52 fjh: next step 14:58:02 tobie: need Rick to review and agree to changes 14:58:09 s/step/steps?/ 14:58:26 fjh: update editors draft, share on list, agree to FPWD 14:58:36 fjh: do not need a perfect draft to publish 14:58:54 tobie: want also to turn issues into spec content 15:00:47 Topic: Adjour 15:05:48 s/Adjour/Adjourn/ 15:05:52 rrsagent, generate minutes 15:05:52 I have made the request to generate http://www.w3.org/2015/06/11-dap-minutes.html fjh 15:16:51 richt has joined #dap 15:19:28 mounir has joined #dap 17:11:56 Zakim has left #dap