16:55:21 RRSAgent has joined #auto 16:55:21 logging to http://www.w3.org/2017/01/30-auto-irc 16:56:43 PatrickLue has joined #auto 17:00:17 PatrickLue has changed the topic to: auto webex for jan. 30: https://mit.webex.com/mit/j.php?MTID=mb30566c23e018cb0ca9841c8fe263c30 17:01:20 paul has joined #auto 17:01:31 rrsagent, make log public 17:01:41 rrsagent, draft minutes 17:01:41 I have made the request to generate http://www.w3.org/2017/01/30-auto-minutes.html kaz 17:02:12 scribenick: ted 17:02:21 PatrickB has joined #auto 17:02:50 Hi all, I can only join on IRC today :( 17:02:55 Present+ Adam, Kaz, PatrickL, Ted, Paul 17:03:54 AdamC has joined #auto 17:04:10 WebEx does not work for me using the link from the original meeting. 17:04:10 Phone does not work over the atlantic ocean ;) 17:04:25 KevG has joined #auto 17:05:18 Present+ Fulup 17:05:56 fulup-home has joined #auto 17:06:58 agenda+ Recap of previous call 17:07:18 agenda+ Call schedule 17:07:25 -> https://www.w3.org/2017/01/23-auto-minutes.html previous minutes 17:07:28 agenda+ Introduce Fulup and AGL 17:07:29 Hi everyone I'm Fulup Ar Foll from IoT.bzh calling for AGL(Automotive Grade Linux)/W3C syncup 17:08:08 -> https://www.w3.org/2017/01/23-auto-minutes.html Previous call 17:08:27 -> https://lists.w3.org/Archives/Public/public-autowebplatform/2017Jan/att-0019/VehicleAPI_UseCases_20170123_PB.pdf Patrick's use cases 17:09:41 PatrickL: we thought it would be useful to have examples to see how the approaches handle 17:09:51 … we discussed this week looking at the scope 17:09:57 Present+ Rudi 17:10:14 Present+ Kevin 17:10:55 Paul: I haven't filled out the survey 17:13:52 @@link to call reschedule survey 17:14:17 Fulup: I am coming from a technical point of view on what is taking place at AGL 17:14:28 s|@@link to|-> http://doodle.com/poll/4fwebn3qdu39hpsu link to| 17:14:52 … we feel implementing ViWi in AGL is pretty straight forward although we have some security concerns that we would like to address 17:16:33 Rudi: what the WG is producing is a different model. what we are doing in these calls is trying to find the next solution based on the various approaches 17:16:49 … some are implementing the current draft 17:17:15 Fulup: we implemented some of the earlier work in Tizen, not worried about implementing a new approach 17:17:55 … what I am more interested in is what would be the widest adopted solution 17:18:07 … there is room for improvement 17:19:01 … I don't have a green light yet about sharing AGL work in W3C 17:19:48 -> http://events.linuxfoundation.org/events/agl-member-meeting AGL AMM in Tokyo on Feb. 8-10 17:20:39 Ted: I believe Dan and I can work out those details 17:21:02 Paul: meanwhile what AGL is working on is publicly visible 17:21:17 Fulup: correct as will the code be behind our implementation 17:22:18 Paul: looking at what you have it is somewhat similar, it would be great to see us converge and have a solution implemented in AGL and Genivi 17:23:53 Fulup: we would like to see cross platform adoption, AGL, Genivi and Tizen... 17:24:12 … we have both sockets and REST, we are finding sockets potentially more useful 17:25:36 https://www.w3.org/TR/2016/WD-vehicle-information-service-20161020/ 17:26:24 http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html 17:27:04 Paul: there are multiple things at play here. the WG is strictly focused on this service specification 17:27:29 … we also have AGL's model and ViWi submission from VW which is in production use 17:27:48 s|html|html Latest Editor's draft of the Vehicle Information Service Specification| 17:27:52 … lastly from cloud perspective PSA+IBM has something that is another 17:28:28 … we presently do not align fully but the approaches are similar and we want to see if we can converge them 17:28:54 … if we adopt the same the chances of success are higher 17:30:54 Ted@@on the 3 17:31:25 Fulup: we found web socket faster than DBUS but we have other transport mechanisms being considered 17:32:20 … the socket performance in the car and the cloud seems better but we are fine with REST as well 17:32:37 Rudi: we chose web sockets for the transport with pub and sub 17:33:12 … as far as the cloud is concerned I am not interested in seeing a direct communication between it and a car 17:33:20 … perhaps better to go through OCF 17:34:00 Fulup: I agree on that. when we talk about cloud we are looking to collect data from vehicles and secure channels 17:34:07 … in some cases REST may make sense 17:34:44 … what is the vision on how to secure a subset of the signals? how will you restrict this access 17:35:36 Rudi: that is part of the specification definition but leaves the details up to the individual implementers 17:36:15 s/subset of the signals/subset of the signals, e.g., geolocation/ 17:36:35 … we figured there would be different models on the backend by tier 1s and oems 17:37:09 Adam: you can have an app specific token that the implementation uses to enforce access rights 17:37:26 Kevin: only certain apps would be permitted to access sensitive data 17:37:56 In the viwi case, you would be able to limit access on 3 levels: service, resource and even element properties, while the later is usually not very practical in real life ---- viwi of course spans multiple domains, so securing "signals" would rather be securing groups of them that you would find in separate resources 17:37:58 Fulup: understood. one thing we are looking in AGL is having an application describe what it wants to subscribe to and consume 17:38:05 q+ 17:38:40 token based ofcourse 17:38:41 … if the API is standard but the metadata on what is being consumed by an application would be more difficult to run on multiple platforms 17:39:46 Kevin: we define get/set/subscribe and discovery. you can get back based on your specification the data permitted. what you get back is VSS tree 17:39:53 -> https://github.com/GENIVI/vehicle_signal_specification GEINVI's Vehicle Signal Specification 17:40:20 q? 17:40:22 ack t 17:44:57 PatrickL: we can try to do some side by side comparison 17:45:10 Paul: that sounds good 17:46:01 Deferring AGL architecture presentation should probably be delay by 2 weeks as next AGL/AMM in Tokyo will happen 8-10/feb. 17:46:39 fulup-home, that sounds good 17:47:28 PatrickL: as an example if i need vin I would first do a search on the document for the API or click through and look at the whole tree from vss 17:50:23 [discussion of where to find in tree] 17:50:45 Paul: VSS is just the data definition, the call would be through the service spec 17:51:35 Adam: via web socket you would say get vehicle...vehicleid 17:51:59 rrsagent, draft minutes 17:51:59 I have made the request to generate http://www.w3.org/2017/01/30-auto-minutes.html kaz 17:52:31 PatrickL: in another example where i have the path available and want to subscribe and get notices every 100ms 17:53:17 Adam: you would send a subscribe with the path of the signal you want and a number of filters 17:53:22 -> http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html Latest Editor's Draft of the Vehicle Information Service Spec 17:53:54 http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html#server-side-filtering 17:54:22 PatrickL: I'll walk us through from ViWi side 18:00:55 http://doodle.com/poll/4fwebn3qdu39hpsu#table 18:01:25 i|doodle|topic: Call schedule| 18:03:29 For those who want to play around with viwi to experience it themselfs, I put my pet project on github, currently focussing on the server parts, functionality of service follows : https://github.com/wzr1337/viwiServer 18:03:46 0600JST, 1300PST, 2200CET, 2100GMT, 1600EST 18:04:43 for next Monday and possibly switch to alternating times 18:06:11 I have made the request to generate http://www.w3.org/2017/01/30-auto-minutes.html ted