Automotive Working Group Teleconference

18 Dec 2018



Hira, Don, PatrickL, Ulf, Ted, Harjot, Ryan, Magnus


<scribe> scribenick: ted

<scribe> Scribe: Ted

Next meeting: 8 January 2019

Moving VISS from CR

Ted: based on call attendees we should largely defer this topic. we also generally covered at the f2f
... where we are with VISS is appropriate for now
... technically we need another implementation report but arguably since there are no requirements for the report could point to write ups of the other known implementations
... as we are seeing more implementations we should see what we hear back as it might influence some minor changes before we finalize VISS v1

Current Spec Status

PatrickL: Ulf presented very good first drafts of his two specs
... I looked into the core specification and want to go through it a bit more


Ulf: I put this up as an initial draft and grabbed the first several portions directly from VISS
... I added a section on data model as well as queries
... security section to add considerations there and then interface where I start describing our existing methods in a generic way
... I am trying to avoid transport specific terms
... as mentioned before I drew from M2M as well

PatrickL: RequestId stands out as something that could get protocol specific
... can you elaborate on its purposes?

[handling of outstanding pull request]

Ulf: only essential information for each method should be there now

PatrickL: timestamp refers to when the data last changed?

Ulf: that too came from VISS but would assume it would be the server response time

PatrickL: in VISS I think it is when data last updated

Ulf: I would like to see it come from the lower layers as well

PatrickL: which could be based on when the system collecting and serving the data via VISS did its polling

Ted: that might be problematic if we are returning a collection of signals, in that case we should clarify most recent

PatrickL: these are details as we go along

Magnus: I seem to remember a timestamp in VSS tree, but unsure what sets it underneath or VISS server

PatrickL: that lines up with Ted's concern. for some use cases I imagine as something that might not make sense
... sometimes not necessary
... or placed for certain signals

Ulf: I was trying to draw from VISS but have no strong view

PatrickL: regarding service discovery, you put it in one of the core methods of the interface
... response can be the tree that is available/exposed
... another idea would be a description of service and data available
... I didn't see it as a method but default on an interface

Ulf: except for create and delete, the other methods were existing ones
... from VISS we had getMetaData but it was not generic enough and was trying to come up with a better name but service discovery

PatrickL: that brings up how we want to construct services
... there will not necessarily be a single service that exposes all data
... whether there will be a single root for the entire vehicle or multiple based on different specialties
... if the main purpose is to learn more about the specific service then that makes sense

Ulf: it could be provided by a single service providing root

Ted: I think we want some form of service capability inquiry _and_ service discovery on vehicle as there may be multiple services
... while possible to use eg VISS to handle multiple services from a top level root, the tree can get massive especially if you consider media libraries
... we should also give consideration to after-market additions that could expose signals to the vehicle as a service

PatrickL: I would like to postpone discovery until a later point
... the Authorize method would be to have the client to send token to service in order to authenticate itself?

Ulf: correct

PatrickL: un/subscribe would be to receive notices for specific signals or rather part of tree
... you would receive proper notification. I question subscriptionID as perhaps protocol specific as well

Ulf: yes but there is value in trying to keep track of which subscription you are handling in your application

Ted: an application can have multiple subscriptions and want to figure out which is responding

PatrickL: transport would be creating new connections that can be tracked handled differently

Ted: subscription id might be useful for developers who might have multiple concurrent subscriptions for their application and depending on their architecture might find it more useful for keeping track of them

PatrickL: there may be places to not return ids
... instead of setting subscribeId to -1 I would prefer an explicit unsubscribe

(from second sentence of section)

Ulf: that came from VISS with some modifications but not attached to it

PatrickL: any other subscription methods come to mind?

Short update on implementation project

Ulf: last time we discussed the repository Magnus setup and wanted to point out there is a start in Go
... others are welcome to take approaches in alternate languages of their choosing as discussed
... there is the start of a client application as well for testing the server

<magnus> https://github.com/MEAE-GOT/W3C_VehicleSignalInterfaceImpl

Magnus: we are not trying to impose a platform. others welcome, we are following Gunnar's don't choose by committee but by code contributions

Ulf: please try to follow the architecture description and join in
... at present it is mainly Peter, Magnus and me

PatrickL: glad to see you that far ahead already, it looks great

Magnus: please drop me a line to be setup as a contributor

PatrickL: anything else for this topic?

Ulf: again join in

PatrickL: enjoy the holiday break, see you 8 January


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/12/20 18:13:52 $