See also: IRC log
<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
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
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