16:00:59 RRSAgent has joined #auto 16:00:59 logging to http://www.w3.org/2017/09/19-auto-irc 16:01:01 scribenick: ted 16:01:01 RRSAgent, make logs public 16:01:01 Zakim has joined #auto 16:01:03 Meeting: Automotive Working Group Teleconference 16:01:03 Date: 19 September 2017 16:02:34 Present+ Rudi, Urata, Ted, Adam 16:03:13 Present+ Kevin 16:03:17 Present+ Mike 16:04:16 Present+ Guru 16:04:36 KevG has joined #auto 16:05:22 Present+ Magnus 16:08:25 agenda+ VISS issues 16:08:57 https://github.com/w3c/automotive/issues/223 16:11:08 Ted @@on_wwwivi 16:11:44 Rudi: any application should be able to find the server without complex discovery 16:11:50 … I am for zeroconf 16:12:53 Ted: it doesn't have to be either or, a fallback could be ivi.local 16:13:16 urata_access has joined #auto 16:13:40 Magnus: I was wondering if we go for zeroconf if we will limit ourself to the local vehicle network 16:14:47 … that would be an issue for cloud services 16:16:43 Ted: intent is to not have the vehicle addressed publicly. an app can take data samples local and send to the cloud or oem may come up with a gateway 16:17:00 Magnus: zeroconf limit us on the number of services on the vehicle? 16:17:11 Ted: no but our wwwivi did... 16:17:43 Kevin: there are a number of scenarios where multiple viss will be exposed 16:17:59 … you may have different product groups working against different instances 16:19:12 … my understanding is you cannot access VISS from internet until it advertises it's public IP address and carriers tend to use dynamic ip assignments 16:20:04 … plus the security concerns are more substantial which is why we were deliberate in creating a private, local service. it is possible to come up with a gateway if truly desired 16:21:15 Rudi: this was always intended as a local service, exposing a vehicle as an internet of things/web of things device would be out of scope for us directly 16:21:55 [OCF, Samsung and ETRI have a vehicle on IoT using our spec] 16:22:02 Kevin: @@k 16:22:22 Magnus: could it be left up to the implementer whether to use discovery or static hostname? 16:22:35 Rudi: we want to solve the portability problem here 16:23:11 … without getting overly complex. the simplest was using a static hostname. the tradeoff is how limiting that is 16:23:38 … zeroconf would give IP and port of the service 16:23:47 Guru has joined #auto 16:24:10 Magnus: multicast doesn't survive beyond its subnet but that might be suitable here 16:25:04 … my concern is we would be limiting the use case, keeping the vehicle local 16:26:01 Guru_ has joined #auto 16:26:27 Rudi: VISS service could be exposed on a public IP and go through a gateway as described if that is really desireable. it would not be discoverable nor would you want that 16:26:38 Magnus has joined #auto 16:30:37 … essentially if we want to put this issue to rest with this method, then we can use viss.localhost as primary and advertise it and and any others with resolver and mdns 16:30:50 Ted: @@on_multiple_use_cases 16:31:22 Kevin: viss would most likely be running on the same [virtual] host as the applications but not necessarily 16:31:57 … clients connecting from the same host on the vehicle would likely connect to the same viss 16:32:08 … but not neccessarily 16:32:19 … we need the flexibility 16:32:41 Rudi: agree and we will need to let additional names to be discovered 16:33:10 Kevin: a default makes sense with ability to find additional endpoints 16:33:52 Magnus: challenge will be in trying to discern which a client would want to connect to 16:34:22 … wouldn't a naming convention help? 16:34:41 q+ 16:36:09 … I am all for supporting multiple servers. in my opinion would be to give multiple IPs for a hostname that a client can iterate over 16:36:39 … see which it is permitted to connect to 16:43:45 Ted @@on other issues and VSS snapshot 16:43:52 Topic: VIAS issues 16:44:39 https://github.com/w3c/automotive/issues/233 16:44:59 Urata: also 232 on callbacks/promises 16:45:09 … this is about API style 16:45:30 … we're using the callback style and Dom suggests promises as a more current convention amoung JS developers 16:46:24 … I answered that basically it was the start Powell did and I wasn't confident in moving that way 16:46:25 https://github.com/w3c/automotive/issues/232 16:47:06 Urata: as I recall we discussed promises in Birmingham and there was not strong opinion in moving that direction 16:47:29 … I understand promises are more common 16:47:52 … I would like to hear other people's opinion. I am not opposed to promises 16:48:32 … in June 2017 I was hurrying to fix VIAS so we could advance it and we were already falling behind schedule 16:48:46 q+ 16:49:53 Rudi: callbacks are the older method, a carry-over from old programming languages 16:50:12 … promises in JS have some synatic sugar and you can daisy chain them together 16:50:21 … functional wise I do not see much of a difference 16:50:37 … perhaps switching to promises will make sense 16:50:56 https://github.com/w3c/automotive/issues/233 16:51:13 Ted: Urata did you see 233? 16:51:21 Rudi: agree we should discuss that first 16:52:10 Urata: Dom questions the viability of VIAS and this is a fundamental question and need to give it some more thought 16:52:42 Rudi: I see his point, this is a rather trivial API with only a handful of functions and it is more of a library instead of an API 16:53:07 … we want to provide developers something they are more comfortable with instead of having to handle web sockets 16:53:35 … another point is they are meant to be extensible, at least the signals 16:53:59 … it would be possible to extend VIAS API with convenience functions for specific interactions 16:54:18 … while it doesn't look like much value at present there might be more 16:55:28 Ted: we know of two VISS implementations but not sure we have someone working on VIAS at present 16:58:18 Urata: actually I have one that is about 50% done 16:58:30 Ted: good, that was going to by my question 16:58:33 @@visteon 16:59:15 Rudi: I have seen Visteon's pheonix being demonstrated and don't think it will be as disruptive, they have been referencing Genivi VSS and our VISS 16:59:35 Urata: do you have a URI? 17:00:01 https://developer.visteon.com/phoenix/sdk.php 17:00:27 Rudi: if you go to architecture you'll see their HTML5 + JS 17:00:44 … you'll see it links out to VSS for the signals 17:00:47 I have made the request to generate http://www.w3.org/2017/09/19-auto-minutes.html ted 17:03:27 Ted: reminder we have a RSI call tomorrow where the focus will be on VSS and signals structure 17:03:34 … it starts an hour earlier 17:04:58 s/@@visteon/.similar to when VW joined and submitted their approach compared to VISS, Visteon has joined and has a robust JS API that they might want us to consider 17:07:02 s/Ted @@on other issues and VSS snapshot/Ted: let's continue on GH issue for wwwivi, I'll experiment with mdns on linux, Kevin please come up cases for multiple services, Magnus we may ask to experiment with your implementation. Do also follow up on the other VISS issues and thank Wonsuk for adding normative reference to VSS/ 17:09:04 s/@@on_multiple_use_cases/previously when wwwivi+mdns came up I didn't like discovery idea since a rogue host may try to compete with the broadcast in order to steal client tokens, mitm or some other attack. we will need to think about the risks this will create/ 17:10:44 s/@@on_wwwivi/[recap of merits of static hostname, how we ended up with it]. if there is a chance of multiple VISS services as Kevin raises then I think we have to go with a zeroconf option/ 17:10:45 I have made the request to generate http://www.w3.org/2017/09/19-auto-minutes.html ted 17:11:14 leaving. As of this point the attendees have been Rudi, Urata, Ted, Adam, Kevin, Mike, Guru, Magnus 17:11:14 Zakim has left #auto 17:11:16 I see no action items