Automotive Working Group Teleconference

<scribe> scribenick: ted

https://github.com/w3c/automotive/issues/223

Ted [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

Rudi: any application should be able to find the server without complex discovery
... I am for zeroconf

Ted: it doesn't have to be either or, a fallback could be ivi.local

Magnus: I was wondering if we go for zeroconf if we will limit ourself to the local vehicle network
... that would be an issue for cloud services

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

Magnus: zeroconf limit us on the number of services on the vehicle?

Ted: no but our wwwivi did...

Kevin: there are a number of scenarios where multiple viss will be exposed
... you may have different product groups working against different instances
... 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
... 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

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

[OCF, Samsung and ETRI have a vehicle on IoT using our spec]

Kevin: @@k

Magnus: could it be left up to the implementer whether to use discovery or static hostname?

Rudi: we want to solve the portability problem here
... without getting overly complex. the simplest was using a static hostname. the tradeoff is how limiting that is
... zeroconf would give IP and port of the service

Magnus: multicast doesn't survive beyond its subnet but that might be suitable here
... my concern is we would be limiting the use case, keeping the vehicle local

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
... 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

Ted: 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

Kevin: viss would most likely be running on the same [virtual] host as the applications but not necessarily
... clients connecting from the same host on the vehicle would likely connect to the same viss
... but not neccessarily
... we need the flexibility

Rudi: agree and we will need to let additional names to be discovered

Kevin: a default makes sense with ability to find additional endpoints

Magnus: challenge will be in trying to discern which a client would want to connect to
... wouldn't a naming convention help?
... 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
... see which it is permitted to connect to

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

VIAS issues

https://github.com/w3c/automotive/issues/233

Urata: also 232 on callbacks/promises
... this is about API style
... we're using the callback style and Dom suggests promises as a more current convention amoung JS developers
... I answered that basically it was the start Powell did and I wasn't confident in moving that way

https://github.com/w3c/automotive/issues/232

Urata: as I recall we discussed promises in Birmingham and there was not strong opinion in moving that direction
... I understand promises are more common
... I would like to hear other people's opinion. I am not opposed to promises
... in June 2017 I was hurrying to fix VIAS so we could advance it and we were already falling behind schedule

Rudi: callbacks are the older method, a carry-over from old programming languages
... promises in JS have some synatic sugar and you can daisy chain them together
... functional wise I do not see much of a difference
... perhaps switching to promises will make sense

https://github.com/w3c/automotive/issues/233

Ted: Urata did you see 233?

Rudi: agree we should discuss that first

Urata: Dom questions the viability of VIAS and this is a fundamental question and need to give it some more thought

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
... we want to provide developers something they are more comfortable with instead of having to handle web sockets
... another point is they are meant to be extensible, at least the signals
... it would be possible to extend VIAS API with convenience functions for specific interactions
... while it doesn't look like much value at present there might be more

Ted: we know of two VISS implementations but not sure we have someone working on VIAS at present

Urata: actually I have one that is about 50% done

Ted: good, that was going to by my question

.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

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

Urata: do you have a URI?

https://developer.visteon.com/phoenix/sdk.php

Rudi: if you go to architecture you'll see their HTML5 + JS
... you'll see it links out to VSS for the signals

Ted: reminder we have a RSI call tomorrow where the focus will be on VSS and signals structure
... it starts an hour earlier