06:10:02 RRSAgent has joined #dap 06:10:02 logging to http://www.w3.org/2015/10/27-dap-irc 06:10:02 tidoust has joined #dap 06:10:06 stakagi has joined #dap 06:10:08 hito has joined #dap 06:10:10 youenn has joined #dap 06:10:12 Zakim has joined #dap 06:10:18 Present+ Tobie_Langel 06:10:27 RRSAgent, draft minutes 06:10:27 I have made the request to generate http://www.w3.org/2015/10/27-dap-minutes.html tidoust 06:10:28 Present+ AnssiK 06:10:35 riju has joined #dap 06:10:39 Linda_ has joined #dap 06:10:46 RRSAgent, makes logs public 06:10:46 I'm logging. I don't understand 'makes logs public', tidoust. Try /msg RRSAgent help 06:10:53 RRSAgent, make logs public 06:11:02 Present+ Tobie_Langel 06:11:17 Meeting: Generic Sensor API Ad-hoc meeting at TPAC 2015 06:11:23 Chair: Tobie 06:11:27 Present+ Riju_Bhaumik 06:11:34 Present+ Francois_Daoust 06:11:40 Present+ Dominique_Hazael-Massieux 06:11:44 Present+ Youenn_Fablet 06:11:45 anssik has joined #dap 06:12:02 Present+ Anssi_Kostiainen 06:12:17 present+ Linda 06:12:49 Present+ Kerry_Taylor 06:13:13 Kerry: co-chair of geospatial, which is in charge of the Sensor ontology maintenance and standardization 06:13:21 wonsuk_ has joined #dap 06:13:28 Dom: Staff contact for Device Sensors API 06:13:56 Francois: W3C Staff, involved in Web of Things IG where sensors and actuators are being discussed; seems like worthwhile alignment in this space 06:14:33 Linda: I participate to the Geospatial WG; I work for Geoknow, a dutch org 06:14:39 ... we have work around sensors 06:14:59 ... I'm also active in the OGC that has a standard sensor API as well; curious about relation with this 06:15:33 Youenn: I'm interested in understanding better the API, both for directly connected and other sensors 06:15:57 ... also interested, how we deal with sensors for which having a dedicated sensor api standard doesn't make sense 06:16:06 Present+ Mark_Foltz 06:16:35 Present+ Wonsuk_Lee 06:16:41 Present+ Lyo_Kato(?) 06:17:22 Present+ Tomoyoki_(KDDI) 06:18:31 Present+ Satoru_Takagi 06:19:14 RRSAgent, draft minutes 06:19:14 I have made the request to generate http://www.w3.org/2015/10/27-dap-minutes.html tidoust 06:20:45 tobie: more and more sensors are exposed directly on devices 06:20:52 ... IoT, bluetooth sensors 06:20:58 futomi has joined #dap 06:21:00 lyokato has joined #dap 06:21:02 ... it would be nice to have a generic way in which these sensors are exposed 06:21:11 ... it's one of the motivations for this work 06:21:14 Present+ Rijubrata_Bhaumik 06:21:34 ... there is also a number of use cases where you need to have access to lower level of sensor data than is currently possible in the Web platform, esp. with high performance requirements 06:21:57 ... e.g. for virtual reality where you need direct output of the gyroscope rather than the typical sensor fusion data 06:22:27 ... The generic sensor API is a small building block, essentially an extension of an EventTarget 06:22:39 ... with the goal of making it usable in a wide range of scenarios 06:22:49 ... right now we're focused on exposing sensor data 06:22:57 ... in a later phase, we'll look at discovering sensors 06:23:11 youenn: you're targetting both fusion sensors and low-level sensors? 06:23:31 tobie: yes; the idea is that specs would determine which type of data they would want to expose (they may expose both) 06:23:50 ... the sensor API gives some guidance on when to expose one, the other or both 06:24:20 ... there are a number of privacy concerns that are the same for all sensors, which this spec tries to define for reference 06:24:53 ... that way, a geolocation api based on this would only have to deal with geolocation-specific issues from security/privacy perspective, not the generic aspects of sensor 06:25:07 ... the goal is to make it easy to write new sensor APIs 06:25:15 ... let's walk through some examples 06:25:20 ... [example 3 in spec] 06:25:57 -> https://w3c.github.io/sensors/#model Generic Sensor API, example 3 06:27:18 ... the spec also has an extensibility section that gives e.g. naming advice, whether to expose high or low level sensors, how to deal with multiple sensors 06:27:39 ... currently the spec imagines that you can have one or multiple sensors of the same type on a given device or in a given environment 06:27:56 ... it leaves the specifics of targeting one specific sensor to specs that build on top of it 06:28:19 Anssi: in the current way we've been dealing with sensors, there is no way to interact with more than one sensor 06:28:28 ... e.g. for the proximity sensor 06:29:09 ... another issue was accessing data of a sensor before any data changes (which a pure event approach imposed) 06:29:27 ... that's how this work is helping 06:29:48 Riju: this was one of the reasons why we had to reimplement the proximity event 06:30:16 ... another one was to be able to specify the frequency of data reading — the generic sensor api lets you set it in the constructor 06:30:47 Anssi: this gives control back to the developer 06:31:09 ... BTW, how do you deal with requests for frequences that are out of bound? 06:31:20 Riju: this is implementation specific 06:31:51 Tobie: there is nothing specified on this 06:32:12 ... the plan is to expose this on the sensor object you get back 06:32:36 mark: can someone describe the sensor reading algorithm? 06:33:01 tobie: it's not described yet — note that existing specs don't say anything on this at the moment 06:33:18 ... one of my requirement is to make it usable with requestAnimationFrame — I'm not sure how to spec that yet 06:33:26 ... (if it's even possible) 06:34:23 Mark: there is the Blink scheduling team that controls the animation frame loop and other timing loops in chrome 06:34:50 Tobie: that's the more challenging part of the spec; I haven't looked into it yet 06:34:55 Anssi: Mark, any pointers or contacts you can share? 06:35:49 Mark: I can take an action to probe them on this; not sure how to help on the spec-ing of it 06:37:23 Tobie: one of my concerns about describing the read-steps is that this makes it specific to local sensors 06:37:42 Dom: this could be an "optional" algorithm based on an internal flag (local vs remote sensor) 06:38:11 Mark: or the remote aspects could be dealt with at discovery time 06:38:36 ... starting with local sensors sounds reasonable 06:39:32 Tobie: I'll need to work with Anne on how to spec this 06:40:23 Mark: another question I had: is this continuous reading or deltas? 06:40:33 Tobie: another great question 06:40:42 ... something that I also need to address 06:40:54 ... for delta readings, you need to be able to define a threshold 06:41:13 ... it seems in most cases, sensor types tie you with a specific mode (at least, it's what android seems to be doing) 06:41:21 ... but I'm not sure yet whether that's always true 06:41:46 ... if it is, this would be a different subclass; otherwise, a parameter in the constructor 06:42:38 Riju: from an implementation perspective, most sensors are dumb, and the content reader has to take care of building a cache and determine whether changes pass a given threshold 06:42:49 ... that's how light and event orientation are down in chromium 06:43:09 Mark: my other question is flow control 06:43:41 ... if a page subscribes to events as a rate faster that it can process them, you end up queuing events, in which case you'll want a buffer, maybe drop some of them 06:44:27 Riju: from an implementation perspective, right now, we tie events emission to page visibility 06:45:25 Mark: but that's only one case of flow control 06:45:50 ... network APIs e.g. have to manage a buffer size 06:45:55 ... this could apply here as well 06:46:04 Riju: I can investigate how this is dealt with at the moment 06:46:20 Dom: what happens if you do prime numbers calculation in an orientation event? :) 06:46:33 Tobie: yeah, I need to look further into this 06:47:13 ... obviously that problem exists only for some sensors (e.g. device orientation), not others (e.g. ambient light) 06:47:46 Mark: my concern is how developers can deal with this 06:48:31 Anssi: maybe something can be learned from the audio guys; they too have to deal with latency for fast-pace data 06:48:57 Tobie: good to confirm that the questions I have are the right ones :) 06:49:47 Anssi: does this match with existing issues? 06:49:49 Tobie: yes 06:50:13 Anssi: when Riju starts the implementation work, this will also highlight new problems 06:52:39 wonsuk_ has joined #dap 06:54:06 [discussion on how to deal with threshold callbacks] 06:54:45 Anssi: do platform APIs provide an optimized way to deal with threshold? 06:55:10 Riju: not that I know; this is something we deal with the bridge to Blink 06:57:35 katsu_ has joined #dap 06:58:43 mfoltzgoogle has joined #dap 06:58:51 Tobie: while the phone sensors are dumb, some of the phones come with smart hubs 07:00:34 katsu has joined #dap 07:01:27 hito has joined #dap 07:02:15 Dom: maybe we could have a predefined list of threshold functions that would work with these smart sensors / smart hubs 07:02:37 kudo has joined #dap 07:02:42 ... e.g. a geo sensor api would have a georadiusthreshold by default, and a way to define a custom one (with impact on perf / battery) 07:04:05 tobie: there are cases where you want batched readings in a single event 07:04:19 francois: I think that was raised in the WoT IG as well 07:06:38 Dom: that's another case where a comparison with network APIs might be useful 07:06:51 ... I know this is something we've been looking at in WebRTC 07:07:00 ... might be worth discussing with networking folks 07:07:08 Anssi: is that something that Streams help solve? 07:07:10 Tobie: not really 07:07:27 Riju: what's the use case of batch if you have frequence? 07:08:18 Tobie: e.g. to smooth the data without having performance cost 07:08:40 Francois: another case is for remote sensors, e.g. with low energy 07:10:20 Anssi: or e.g. radio communication from the sensors 07:10:58 Kerry: a related question: there seems to assume that a given sensor only deals with one type of data 07:11:09 scribe: tidoust 07:11:25 Kerry: Remote sensors may have more sensors per physical sensor 07:11:57 Tobie: For sensors that have, say, temperature and location, you would have two sensor objects that would be independent. 07:12:17 Kerry: But they would not be independent, typically because you would want to batch the transmission. 07:13:30 Tobie: One sensor object is tied to one physical property. If you have a sensor that combine many of those, then, what you really want to do that is out of scope of this specification is to have an object that contains a number of these sensors. 07:14:24 ... That's what the Web of Things IG is considering. 07:16:23 Francois: Such sensors would generate only one "change" event with one timestamp and a bunch of properties, right? 07:16:39 Tobie: Right, so you could use SensorReading to define that bunch of properties. 07:17:05 Dom: That ties in with Youenn's initial point at the beginning of this session realted to custom proprietary properties. 07:17:35 Tobie: Can you generate an object with ad-hoc property values? I don't know how to do that in WebIDL. 07:17:43 anssik has changed the topic to: Generic Sensor API ad-hoc meeting https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API 07:19:21 Dom: If there was a magic function to address custom sensors which you want to read, you would discover the sensor, which will give you the type of data. When you instantiate the sensor, you get an object that implements that data model. 07:20:20 Francois: OK, that matches discussions in the Web of Things IG, I think. 07:20:43 Tobie: Could this be mapped to postMessage/onmessage? 07:20:51 Dom: That's a good question 07:21:38 Tobie: That would give you a way to listen to readings that are essentially a JSON message. 07:22:02 Dom: Pushing the comparison with networking, is there any reason why we don't adopt the same pattern? 07:22:35 Mark: Networking is a pre-agreed protocol between two sides. How does the Web developer find out what the protocol is with the devices? 07:22:49 ... I don't think we should tie it with the data you get back. 07:23:33 Dom: You could do both. Concrete API, or a "generic" API that would allow to get custom properties. 07:23:54 AdamC_ has joined #dap 07:24:23 Riju: What I understand from this discussion is something like instantiating the Sensor object 07:24:36 Mark: There's a constructor in the WebIDL. Why is it here? 07:25:40 Tobie: I'm thinking about it. A few specific use cases that may need this. 07:25:56 ... I still need a place that explains what should happen in the constructor, in the Extensibility section. 07:26:58 Dom: High-level question is: does it need to be addressed right away? Then there is the question of possibly converging with postMessage/onmessage pattern. 07:28:01 ... One of the things you can do with WebSockets and WebRTC data channels is sending the events through the network. 07:28:19 ... You get these events through a postMessage/onmessage event. 07:28:41 ... There may be value in reusing that pattern. 07:29:23 Youenn: So you would have a Thing API where you would have "onmessage" to receive readings and "postMessage" to send updates to the thing. 07:29:36 Dom: Right, I'm just thinking out loud there, so that may not be a good idea. 07:30:10 ... It may be a tiny detail. 07:30:51 Anssi: For random sensors that are unspecified, could you elaborate on that? 07:31:22 Dom: Imagine you get some kind of objects that correspond to some sensor you want to discover. The browser does not know about the sensor but the application does. 07:31:36 ... Perhaps because of discovery query options. 07:32:18 ... We will likely have a Servometer API but we're unlikely to have an Altimeter API for instance, and yet that could be useful to access such sensors. 07:33:01 ... What the thing is would be part of the Discovery mechanism. 07:33:17 s/you want to discover/you have discovered/ 07:35:02 Mark: A couple of thoughts. If it's really a protocol between the browser and the sensor, then what is the value of the Generic Sensor API there instead of navigator.connect? 07:35:43 Tobie: This is the reason I have the Constructor in the spec. To have such conversations. 07:36:22 ... The added value is for companies that create new sensor objects to make them available to JS libraries that know what to do with them. 07:36:45 Mark: I don't understand how you map this sensor interface with the JSON messaging that you would have. 07:37:15 ... What would frequency mean? What would batch mean? 07:37:29 ... If it does not mean anything, you just map the API on top of the raw socket 07:37:51 Dom: That's something to look into. I don't think we can have a clear decision in this room right now. 07:38:15 Tobie: OK, I have to think about this. 07:39:00 Mark: Another topic: It seems these sensor objects are expensive. Do users control the lifecycle of these objects or should the API expose some disposal mechanism? 07:39:24 ... With event handlers, you have to be careful so that they can be garbage collected. 07:39:51 Dom: What is expensive is the callbacks. 07:40:42 Tobie: If you don't have handlers, you can stop listening to data. 07:41:34 Riju: In OIC, we do discovery where the sensors have specific IDs and choose which one to use. 07:41:45 s/OIC/IOC/ 07:41:50 https://www.iotivity.org/ 07:42:15 https://github.com/otcshare/iotivity-node 07:43:56 Tobie: I did not add a stop message, but if you have 20 gyroscopes in your phone and are only interesting in one, you do not want to start listening to the 20 gyroscopes. 07:45:22 Francois: Talking about this, the ability to list devices discovered is problematic from a privacy perspective. 07:45:33 Tobie: Right, that's why I will remove matchAll for now. 07:45:56 ... But the start/stop question is still important. 07:46:31 ... It would allow to instantiate sensors that I'm not going to use for everything right away. No need to have sensor info. 07:47:10 ... It solves a bunch of problems. 07:48:42 Tobie: Let's break. After, I'd like to list APIs with automotive folks in the room for instance that could use that Generic Sensor API. 07:49:44 Mark: We ran through the same kind of discussions for the Presentation API. Ended up with the PresentationAvailability object. The implementation can suspend the availability monitoring at any time. 07:50:01 ... One solution to control how often this kind of expensive operations run in the background. 07:50:17 https://w3c.github.io/presentation-api/#interface-presentationavailability 07:51:58 RRSAgent, draft minutes 07:51:58 I have made the request to generate http://www.w3.org/2015/10/27-dap-minutes.html dom 07:58:48 kudo has joined #dap 08:08:46 i/Francois: W3C Staff/scribe: dom/ 08:08:52 RRSAgent, draft minutes 08:08:52 I have made the request to generate http://www.w3.org/2015/10/27-dap-minutes.html tidoust 08:11:07 i/Dom: Staff contact/scribe: tidoust 08:11:16 i/Kerry: co-chair of geospatial/scribe: dom/ 08:11:39 Present+ Katsuyoshi_Naka 08:11:59 riju has joined #dap 08:12:20 [break] 08:12:42 Tobie: I would be interested to look into existing APIs and see how they fit in the spec 08:12:50 ... Other interests? 08:13:07 Dom: Before that, some rough idea in terms of roadmap? 08:13:26 Tobie: A bunch of things still need to be added to the spec and/or clarified. 08:13:55 Dom: The plan is to plan a draft concrete API and see what emerges from there? 08:14:17 Anssi: Yes. For the Ambiant Light API. 08:14:45 ... No need to polish the implementation. Riju can do it in a private branch. 08:15:01 ... We will push it when we consider it is final. 08:15:51 Tobie: Then I think we need a spec such as the Device Orientation spec to ensure that you cover all the needs. 08:16:07 Dom: Do we have anyone lined up for the Device Orientation spec? 08:16:32 Anssi: We may be able to do something there. Tim is in the loop. 08:17:30 Dom: OK, so a potential editor for that spec. 08:18:07 Riju: Proximity, Ambiant Light, I can take care. Battery Status. 08:18:14 Dom: any other big one? 08:18:27 Tobie: No, the Device Orientation is the big one. 08:18:37 Dom: I wonder how many we need to validate the approach. 08:18:58 Tobie: I don't think that's how many but rather how many different types you have. 08:19:11 ... You want sensors with multiple values. 08:19:13 tomoyuki has joined #dap 08:19:27 ... I'd be happy to have Ambiant Light and Device Orientation as outcomes. 08:19:44 s/Ambiant/Ambient/g 08:19:55 s/ambiant/ambient/g 08:20:18 Tobie: Then there is also the question of supporting remote sensors 08:20:40 Dom: We could have a v1 for local sensors-only, and v2 that supports remote sensors as well. 08:20:52 Anssi: It's important to set expectations. 08:21:32 Tobie: The last spec I could be interested to have is Geolocation, because it has specific requirements around cached data. 08:21:58 Dom: That particular implementation of the Geolocation API could be done in the Geolocation WG, which would be a good thing to further validate the approach. 08:25:45 Tobie: I have a very light polyfill for a few specs, including Geolocation, although based on a previous version of the spec. 08:26:05 Tobie: Any API you would like to test as a Sensor API? 08:26:25 Adam: Yes, from an automotive perspective, that would be interesting. 08:26:36 http://rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html 08:28:05 Adam: All of this stuff will be coming from a network. Could that be defined as a sensor source? 08:28:20 Dom: Do you want some way to say that you only want this data only x times per second? 08:28:40 http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html 08:28:40 Adam: Yes. The subscription mechanism lets you specify that. 08:30:45 [Tobie projecting a text editor to work on one of the interfaces] 08:31:52 hito has joined #dap 08:33:17 [Discussing adapting the VehicleInterface and VehicleSignalInterface] 08:34:04 Adam: concept is to define a door interface from which you can subscribe to the front left door and so on. 08:34:34 Dom: This would rather be an array of doors that you listen to in the sensor API approach 08:36:32 mats has joined #dap 08:37:58 Tobie: Essentially, that would reverse the way you approached it. var sensor = new DoorSensor({ zone: "front left" }), and sensor.onchange = ... 08:38:52 Adam: I think it is similar to how the implementations are setup. 08:39:32 Tobie: This would reuse the event system of the platform, instead of creating a new pub/sub model. 08:40:12 Dom: One thing that is useful is to define one type of event handler that will be used to process many different types of events. It only works provided the event model is the same for everything. 08:40:50 ... For an app willing to interact with automotive APIs only, it's ok, but otherwise it makes things more painful to develop. 08:41:26 tomoyuki has joined #dap 08:45:22 [More work on the blackboard on interface definitions] 08:52:05 Dom: Are there cases where you need actuators that would not be sensors? 08:52:09 Adam: No, I don't think so. 08:54:29 ... Fundamentally, nothing is really going to change in the Generic Sensor API? 08:54:36 Tobie: It depends on your timeline. 08:55:07 Adam: Q1 2016 for Last Call equivalent. 08:55:26 Tobie: We should have some good definitive answers by January. 08:56:20 Dom: That might be too late for the group to re-write the spec. 08:56:53 ... Do you think it is likely that you could converge to that approach? 08:57:08 Adam: I like the idea of converging to a more Web-like approach, but I need to pass it through the group. 08:59:12 Francois: Migration to DOM events does not necessarily mean depending on the Generic Sensor API. That's something that would provide the first bit of alignment and that the Automotive Working Group could discuss and enact on their own. 08:59:17 Adam: Right. 08:59:24 RRSAgent, draft minutes 08:59:24 I have made the request to generate http://www.w3.org/2015/10/27-dap-minutes.html dom