Meeting minutes
Implementation notes
Peter: brief report for now, I started an implementation based on fork from VISSv2 reference implementation
… goal is to have it running in a vehicle soon. I'm using another open source project to feed southbound signals
… bimi (sp?) broker which started at Volvo but now elsewhere and flexray
… I'm using a record/playback mechanism for testing VISS via bimi
… setup a 'vehicle' on a rpi
… Ulf's implementation is working, using dockerized composition from Magnus which is also working
… the plan here is to use this to populate VSSo in the cloud
Ted: presumably Joakim will jump in on VSSo part?
Peter: yes, guess that is it for now
Ulf: glad this is being used
Peter: hope to have more progress in a few weeks and a vehicle with hardware that can support it
Gunnar: when mapping signals from flexray to VSS, are you using a configuration file to map?
Peter: I have some ideas on how to do that. that is one of the challenges here, low level work
… there are lexical similarities between the models that may facilitate
Ted: that is going to be a common problem for others, would be great if we can generalize it
… we have to do that often ourselves
Ulf: it is arduous indeed, think Peter was looking for automated mapping
Peter: that is my thought based on similarity of naming, not sure how far you can go with it
Ulf: not all the way but a good start
Gunnar: we have a similar exercise elsewhere, eg for Android
Peter: there are a number of useful tools out there, hopeful we might be able to achieve something
… there may be gaps between the mappings, eg additional signals not in VSS
Ted: immediate solution is to use private branch and encourage contributing those for consideration back to VSS
Issues and PRs
Ulf: perhaps we can first hear from Isaac on his thoughts or progress on revision from last time
Isaac: too early to present, should have more by next week
… perhaps a summary for the callers here worthwhile
Ulf: let's defer and cover next week
https://
Ulf: first off thanks to Gunnar for helping sort out PR mess last week
https://
https://
Ulf: we were inconsistent in providing timestamps and concluded we should be uniform
… getSuccessResponse had timestamps for data points but not the time for the response itself
… this PR contains more than just timestamps as I noticed the format for the responses was using old way of representing data points
… it is possible to return multiple data points in one response
… I addressed both in this PR
… I consider this a minor PR and propose we adopt it
Ted: agree, let's go with it
https://
https://
Ulf: this relates to tokens in transport, how they can be used
… there was only one example but we have different types of requests
… this one should be fairly straight forward as well, using tokens for slightly different requests
… the main thing here is "A token header can be combined with all types of update requests"
… this one is fairly straight forward. unless people feel more is needed, suggest we accept this change as well. it meets and resolves the raised problem
… I encourage people to read through the other PR on their own as I wasn't part of it
Ted: let's discuss that one next week
https://
[closing 387. 399 only half addressed at present]
https://
Ulf: while we have multiple underlying datatypes in VSS but in the actual JSON payload it is sent as a string
… I claim there is value in having it as a string
… crea7or pointed to C locale and JSON RFC, my leaning is to the latter
… I could produce a PR but want to get input first
Gunnar: doesn't it need quotes to be strings in JSON?
Ulf: quotes make clear it is a string but not required
Gunnar: this comes from JS typing
Ulf: my question is are we ready to consider a PR adding this
Peter: I think its needed
… ran into exactly this with southbound translation
Ted: perhaps try to get some feedback from Sebastian first
https://
Ulf: that is a good point, agree consistency would be better
Ted: agree
Peter: seems straight forward
Ulf: I'll address and use arrays
https://
Ulf: the question is should it be possible to set more than one signal in a request
… at the time I wrote it, thought so but now hesitant
Ted: for locking all doors, same node as suggested, makes sense but not across nodes
… access control per signal write could prevent. think child window/door lock - don't let the kid in the backseat unlock all doors
Gunnar: I wonder if such policies (access control) would take care of it
Ted: agree
MagnusG: how are we handling error response if eg one is refused?
Ulf: it could be all fail and underlying system should revert
… that may be a pain for implementations
Gunnar: yeah we would have to support transaction rollbacks
… recall the previous discussion that setting a target value may take some time, not produce immediate results
… you might need to eg read back repeatedly to see progress of window being lowered
Ulf: some of this belongs more in VSC than VISS
… the client can check results and act accordingly