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