<scribe> scribenick: ted

<scribe> scribenick: ted

Target audience

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

Patrick's Target Group

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

Grouping

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