Automotive Business Group Teleconference

<inserted> Discussion point:

https://www.w3.org/community/autowebplatform/wiki/ViWi#Open_Discussion_Points

Paul: a couple of these open discussion points came from PatrickL and I added the others
... you are gluing a web runtime to a host vehicle
... we discussed domains in a vehicle before
... we want to give a developer a common way of accessing information instead of a mixed and matched approach
... really it comes down to REST or not
... web sockets make sense for signals not so much for media tuning

Fulup: I haven't discussed what we do in AGL yet and we do both in a common way
... we merge and use the same mechanism
... we don't really care about the transport layer, we have an abstract layer
... for media REST or DBUS is good, not as much with signals where we use sockets

PatrickL: you need to have a fast way to get a signal and why we include web socket in viwi
... we wanted the HTTP part as well

Paul: do you have an API layer above all this and use the protocol that makes sense?

Fulup: it comes down to the data processing that should influence the delivery

PatrickL: one API side (socket) is there to get new information quickly and have the more structure of REST
... developers should be more familiar with the REST approach
... in order to get the continuous data stream you need something like sockets in HTTP1.1, in HTTP2 there may be more options

Fulup: we have a separation between the rendering of client app (HTML5 or QT)

Fulup: UI to business logic we use REST or web sockets as something that developers understand

Paul: a higher level JS client API, which some want, abstracts out the transport layer. we focused on the service layer first
... one reason against two protocols is increasing attack surface but there are counter arguments to that

PatrickL: what direction would we take in trying to examine REST being more vulnerable?
... we saw there were reasons for structuring viwi in a REST way

Kaz: WoT WG is working on an abstraction layer and protocol agnostic module
... that might be interesting here
... they are including REST and web socket bindings

Paul: at the end of the day, the information model matters as much if not more than the transport

Kaz: WoT is interested in integration of REST and web socket

Paul: I looked at Iotivity and others and they are doing both

Kaz: WoT is working with OCF's work including IoTivity and oneM2M's work in their plugfest

Paul: information models for different domains besides just vehicle signals are a big part of this

PatrickL: we are thinking of additional domains besides what we have initially in viwi

<PatrickB> For us the separation of concerns by using the REST approach brought a lot of value in definition, implementation,scalability and testing on either end, client and server

Paul: we listed these various domains in the past, areas we want to get into besides signals

Ted: there is an advantage to having the same programming paradigm across these various domains from the developer perspective. as an example an app might want to poll vehicle data on fuel level, inform LBS of the need for a detour and the media system will need to pause to inform the driver

PatrickL: we should focus on why a consistent programming paradigm is beneficial

Paul: having to shift programming models can throw developer teams

Fulup: agree with thinking of the developer but also need to think about the implementer, having same paradigm for different domains is beneficial for debugging, service archicture etc
... I do not see being able to handle the whole wish list of domains in the same model though

Kaz: WoT is working on Thing Description that abstracts out domain

Paul: everything becomes a thing

Urata: I have a question. My understanding of the goal of this discussion is to integrate our web socket spec with viwi
... is there a schedule for reaching a conclusion?

Paul: I am looking for points of convergence but agree we need to think of a timeline
... we are expecting possibly some more people who are more into the JS client level and not even thinking of a common service
... architecturally where do these pieces fit, from there we can figure out what to put in a new specification
... I am not hearing anything at odds
... the VISS goes to CR in April and in May we should be talking about the next focus for the WG
... see if we can get a common architecture for multiple domains

Fulup: AGL has a big meeting in the Summer where I would like to present a strategy
... if there is something drafted by October it can make it into this year's release

Ted: through these calls we should have the start of plan before the F2F in May

<fulup-iotbzh> When where is May F2F ?

Paul: we should have an architectural diagram that explains the various pieces (like what Kevin did before)

fulup-iotbzh at Genivi AMM in Birmingham. 2 days but specifically which is not decided yet

<kaz> GENIVI AMM in May

Paul: information model, supporting multiple domains is what we want

<fulup-iotbzh> I will attend Birmaingham meeting, also not a problem for me.

Paul: architecturally you have service layer and also client JS layer
... the BG will submit a report to the WG

Wonsuk: I fully agree. In my point of view is that we need to make a result based on our consensus so far
... it is worth taking a step back and looking at the other domains
... Media or LBS should be next
... concerning protocol, that is a priority. there are benefits for both sockets and REST

Paul: I agree we need to pick next targets, align information model with protocol, see if it works and adding REST if appropriate

Kaz: agree as well with sending this proposal to the WG given this proposal would impact the WG deliverable spec. also possibly we could include both the original WeSocket approach and VIWI approach as possible two profiles within the spec

Paul: what are the other domains that viwi currently handles?

PatrickB: CDN, media library, media services, vehicle signals

<kaz> VIWI proposal including 5 domains

PatrickB: thinking forward notifications would be very useful for autonomous driving
... we have those already defined they're just not public

Ted: based on Wonsuk's comment earlier about BG TF let's look at media next as a domain
... there is an advantage to having the same programming paradigm across these various domains from the developer perspective. as an example an app might want to poll vehicle data on fuel level, inform LBS of the need for a detour and the media system will need to pause to inform the driver