Automotive Working Group Teleconference

28 Aug 2018


Benjamin, Ted, Ulf, Magnus, Hira, PatrickL, Tim, Laurent, Hira, Paul, Joakim, Peter
Patrick L



PatrickL recaps previous meeting


PatrickL: URI seems the obvious scheme to use and want to start with that here, see if there is agreement

Ulf and Ted concur

PatrickL: good, let me push the envelope and see if you won't agree...
... the protocol scheme we would like to use would be like viss

Ted: so we would be defining our own protocol?

PatrickL: did we settle on http[s]?

Ted: i could see protocol-less before creating a custom protocol but that would be difficult for implementers

Ulf: why are we discarding http?

Laurent: how (the protocol) we access the service is not important
... how matters less than what comes next

PatrickL: the where (hostname) comes next. your client needs to know where to find what you are accessing
... IP addresses and DNS name resolution is fine here. it is not that important to know the where if there is a service registry
... that brings me to the path part of the URI and it describes what we want to have
... it would be ideal if the path describes explicitly what we are accessing
... how, where and what in the URI and we should focus mostly on the latter, it is what the developers are most interested in
... does that make sense to all?

Ted: it does to me

PatrickL: next part is the querystring, what comes at the end of URI after ?
... addressing scheme then becomes how, where, what and then more selective and consistent with the http world

Ulf: sounds OK to me

Laurent: what is the fourth part?

PatrickL: querystring, acts as a filter or search

Tim: I am trying to visualize how the path would be used differently than the querystring

PatrickL: path would describe what the developer is looking for, in media example list of artists, and then a filter for specific artists

Tim: a modifier
... ok, sounds sensible

PatrickL: not a new idea, making sure we are on same page when it comes to addressing

Tim: will we use HTTP verbs as well?

PatrickL: they are generally well known and observed, well some don't know PUT etc...
... it would make sense to use verbs from HTTP

Tim: in VISS web sockets, action is in the body. while that is a way to go, I would prefer to use an existing protocol

Ulf: I think the complete specification should support more than one protocol, HTTP and Web Sockets

PatrickL: there it would make sense to use multiple protocol schemes, they can access based on developer preferences/needs
... ideal would be consistent verbs and support MQTT, WS, HTTP, etc

Tim: it feels that might get sticky with the nuances of the different protocols
... MQTT does not have the same notion of verbs
... a least common denominator would be preferred for consistency
... not sure how we can make that work though

PatrickL: my intention was to make it possible to adapt the way we describe data to multiple protocols and keep consistent with a RESTful manner
... try to stick with as much as possible with HTTP for the others

Ulf: I agree with the statements expressed

Laurent: it is nice to reduce the load on the developer

<PatrickLue> <how>://<where>/<what>?<filter_and_so_on>

Laurent: MQTT is not that far off, in the end we are transfering a payload
... agreeing on payload itself is important. their verbs are close and not really shoehorning one into another
... as Ulf said in his email you can figure out what to do where (in viwi vs viss)
... we have to recognize signals are different than other "resources"
... we can agree on the broad strokes and need for subscriptions

Tim: sounds good to me

PatrickL: we are going rather quickly and see we are in agreement

Ulf: I am hesistant in using CAN bus style that you mentioned, in my opinion that should be abstracted and that is too internal
... that would lead us to debating LIN and Flexray

PatrickL: I agree, that was the old automotive guy in me using it as an example

TO DO list

PatrickL: looking at todos list for next topic, service registry perhaps


PatrickL: I am bitten by the microservice bug, I am starting to see them everywhere and use to solve everything
... they can be built quite well by a department within a vehicle realm and tied together
... everyone is responsible for their microservice and in order to bring them together, need a registry to find them
... that way I do not need custom configuration for a vehicle
... for me that is a registry. a developer would be able to go through a registry to see all that whats that are available
... that way if I am looking for a specific thing, I can take a look in registry for it and learn which service provides in with which protocols and address

Benjamin: I know nothing about microservices, can you explain what you can combine, how it works?

PatrickL: you build a function and provide an API to it through a service
... you access it through TCP/IP over the network. think of it like classes scaled to a network level
... instead of compiling all those classes together to use functionality it is more a living world
... services can use others

Benjamin: sounds auto specific

Ted: you can think of these microservices on vehicle like a microcosm for the web - registry is search engine, media is your content, etc and developers are coding interactions with them

Joakim: do you see different parts of the specification implemented by different services?

PatrickL: I would like to go to our media department and tell them how I want to access their offering through a service and they would provide it

Joakim: modifier (querystring) doesn't really apply well to signals, once you are subscribing there is no need to filter

PatrickL: a developer might be interested in accessing information only about the driver's seat and not all seats

Joakim: in some cars you can change the configuration
... eg different number of seats

PatrickL: yes but I should have a static representation of all seats and could either handle it within my (developer perspective) code or offload to server with its filter capability
... we want to be able to handle both, correct?

Magnus: wouldn't having a service registry break the idea from VISS of having different branches offered by different services

Laurent: just because we have filtering, you don't have to use it
... the registry helps you find stuff. now if you decide to implement an endpoint under a single service host, that is your decision
... registry could be next to or even same server as VISS

PatrickL: it breaks the mental model of VISS, it is not necessarily a one stop service
... from an implementation standpoint, the VISS model would need to proxy all information from potentially different sources

Ted: we have the same issue in VISS. earlier we envisioned the possibility (due to implementer choice, different trim levels for a make and model or aftermarket integration) of multiple VISS servers in the vehicle. I believe the spec reflects that but doesn't describe how nor how to handle broken branches. we don't have a solution yet

Tim: I am reminded of a service I use where the core server provides URIs for other services
... that registry service, if request recognizes it, provides notional server id[s] for microservice[s] that provide desired functionality

PatrickL: that makes sense to me

Ulf: if we have a tree in the specification, I don't really like separating the registry from the tree
... having separate logical parts found at different locations is a dangerous path
... they may contain similar information and you want to avoid exposing something multiple times
... we should strive after one structure containing all we are talking about, if we have a tree at all

Tim: I agree but what it sounds like to me is the registry is the root of the tree
... it can tell you the branches it presents

PatrickL: I can have engine and trailer service implementations in two places. I can either try to address both services independently or have a registry expose both
... regarding having things defined at multiple locations, I agree that is not desireable

Joakim: if the tree is both the API and the modal, couldn't the registry return the nodes available on a given car?

PatrickL: definitely
... one of the arguments for the tree in the VSS is that it is searchable based on partial path and *

Joakim: you can either access the tree or ask what nodes are available

PatrickL: it works that way but requires multiple connections

Joakim: another concern is adding complexity when we should be working to make it easier for devlopers

PatrickL: it would be easier if all the information was available in a central location
... am I correct in hearing pushback from the group on concept of registry?

Ted: I see it more as hesitation and if the group understands how you are doing your registry more they can get their heads around it

PatrickL: I can do that next week

Ulf: in a simpler model you would not need a registry unless you are adding or subtracting nodes


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/08/28 22:15:21 $