<scribe> scribenick: ted
<scribe> scribenick: ted
PatrickL: I see the main audience for what we are creating the developers. an API is a good API if they can readily use it
Glenn: that sounds like what we are trying to accomplish
PatrickL: microservices could
provide similar APIs and used by other applications
... you could provide multiple competing services
... is this an approach we want to accomodate, allow several
real instances of data providers
Magnus: I think they should be out of scope for this group. how the underlying ECU are available within the vehicle is up to the OEM
PatrickL: that is a good point, we want to be agnostic to the underlying vehicle network. however I want to be able to use this framework
Magnus: we discussed the possibility of multiple VISS on a given vehicle
Guru: I have the same opinion as Magnus and reminded of VIAS client which is becoming a note
Gunnar: I agree you should be able to implement more than one service
Ted: another example of multiple services is for aftermarket where customization may provide additional functionality that could be exposed to applications on head unit and permitted devices
PatrickL: does the group agree:
distributed implementation of interfaces of the frame work is
possible
... example door ECUs to have N implementations of door
handlers, each with its own copy of API
Ted: Valeo@@
Magnus: I could see multiple door
services. from my point of view we could have services
available inside and out of the car
... we should be able to support them
Ulf: would this be transparent?
PatrickL: the addressing of
elements or group of elements would need to describe where to
find it, network address
... something like linking becomes important for the API
Mike: are these APIs currently being developed?
<KevG> Hi Ted, I've raised my hand in WebEx, not sure if need to flag here as well, thanks
PartickL: we are currently
building systems this way
... what we are currently talking about is version 2, what we
would like to see
Urata: my question on
microservices is what point will expose vehicle data to the
browser
... would my application speak to one point or individual
<KevG> Believe supporting distributed implementations is fine, but would suggest that we are essentially trying to define a (Directed Acyclic) graph of objects. My suggestion would be to try to follow approach used in CSS and JQuery
<KevG> Specifically, each node in graph always has a unique id and has a class e.g. 'door'. It can then have other attributes that could be used to support filtering
Urata: we want to avoid developer confusion from several different data output points
PatrickL: my opinion is that it is ok for a developer to look at a second point for data
<KevG> Important attribute would be location. Hence the graph could then be a logical structure with attribute that defines e.g. where the component is fitted - which might vary from one model line to another
PatrickB: it rather important to
allow for things like this. there will be different servers
just like on the web
... in the car it can be different ECU and we do not want to
enforce an aggregator architecture under a single API
... we talked about trees and subtrees which logically
works
Urata: how is an application suppose to find these various IP addresses and port numbers of different services?
Kevin: I don't have a problem
with distributed implementations. we have an object graph that
works well witih things like jquery and css selectors
... we want to make it easy to work with the object graphs
available in the vehicle
... xpath is another way
... jquery and css are incredibly powerful, you can select all
doors, a single one or its parent
PatrickL: how does that relate to distributed services?
Kevin: if I have to go into a
discovery system to find doors, query them separately and
combine results that would be more onerous
... perhaps there is a way to query across services clearly in
a distributed manner
PatrickL: would an aggregator serve your needs?
Kevin: we need to be careful not to make things difficult for the developer
PatrickL: is this query capability important to JLR?
Kevin: yes
PatrickL: to avoid going too far
off topic, let's discuss query next week
... give people time to form their opinions
PatrickL: how do we want to group
our APIs or at least the datasets
... from the two influences as input have people given thought
on data clustering?
... for instance why you see tree as a right way or list of
structures in services
Gunnar: don't all the solutions have some tree structure?
PatrickL: I don't see a tree in
RSI
... similar lists of data elements as resources which have
elements that interlink to other resources
... not a clear graph. you can grep a root and get one element
of a graph behind it and not a tree
Gunnar: you still have a hierarchy and then linking
PatrickL: that is not there for
the data itself
... I want to bring data elements together in a manner that is
in a logical subgroup eg engine
<KevG> Using CSS selector like approach where each node in graph has a unique id allows developers to easily check for deep equality (obj1.id == obj2.id), but can also support concept of shallow equality. Plus can do all of the neat things that can do with CSS selectors and jQuery e.g. select all objects with class 'door'
PatrickL: want to have a grouping
that is logical for the developer. there should not be row for
example as a grouping element on doors
... groups can be combined as logical such as all doors,
windows etc as part of body
... below I want easily understandable objects
... this is why people want to see a flattened view of data
elements
... there will be more details on the wiki
<PatrickLue_> https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework#
Urata: for me the levels of
grouping is similar to tree structure and VSS there is such a
concept
... is it different?
PatrickL: different
Gunnar: design goal is grouping
and organization in general
... if there is a big difference between the API and the
signals that would be more difficult to implement
PatrickB: aren't the differences so varied among the underlying OEM anyway plus move towards flexray and other networks?
Gunnar: there are a range of things, including SomeIP
PatrickB: do we have expertise in the group on these different networks and their signaling?
PatrickL: Gunnar, do you have someone in mind who could join a call?
Gunnar: either myself or someone else
PatrickL: having the group understand SomeIP is a good idea. most here understand CAN and should understand this new paradigm
Magnus: arent't we diving too
deep? we are working on an abstraction layer
... yes it should be influenced by the underlying
structure
... not sure we need to understand flexray, SomeIP etc
PatrickL: I think Gunnar wanted us to fit several styles in the vehicle
Gunnar: we might need to split
between signaling and other types of APIs
... we do want some understanding so that it is reasonably
implemented
[adjourned]
<KevG> Most vehicle networks will not have all CAN signals available in a single point on a vehicle and different models may have different CAN network architecute designs. Also data will likely need to be cached so that last available signal can be viewed (in case current signal of interest is being blocked by more important signal on the CAN Bus. So OEMs are going to have to put in significant effort in updating vehicle architectures to make these signals available