<scribe> Meeting: RPC Breakout call
<scribe> scribenick: ted
<scribe> Scribe: Ted
Defer on Review of JLR repo contents topic until subsequent call
MagnusF: I think we agreed on a binary protocol and that eliminates JSON
Gunnar: unless we want to support both
MagnusF: is WAMP binary?
Gunnar: I think they officially support JSON and Message Pack
MagnusF: that would be a strong contender
Gunnar: Message Pack is quite
similar to compression scheme we were discussing for data
service
... it keeps a structure similar to JSON
MagnusF: Steven, you want to go
through WAMP with me as a potential
... any other that support binary and structured data? GRPC
Gunnar: yeah
... it has some relationship with HTTP2
https://en.wikipedia.org/wiki/GRPC
Peter: we used GRPC for signal broker we open sourced, it is very usable
Daniel: likely more widely used than WAMP
Gunnar: but WAMP is far more capable
MagnusF: do we know how heavy
GRPC is with dependencies, etc?
... ok, Steven and I will compare these two
Steven: GRPC is widely supported
in various libraries, Java, Python... but no C
... actually it is but not listed on wikipedia page
Gunnar: there are RPC on zeromq too
MagnusF: there seems to have been
some bitter infighting on that
... ok we can look at nanomessage as well, small payload but
not sure it is that stable
Steven: it was a number of years since we looked at it. think contributing back upstream was difficult
MagnusF: we also need to look at
security/robustness/efficiency...
... Steven, we commissioned a report from Collabora which is
public and we can share it
Steven: I referenced it recently and can find it
MagnusF: good side by side
including dbus comparison, those metrics will help us
... any other considerations?
Ted: we want to potentially align to the extent possible RPC with Gen2 where we are also considering binary formats in addition to JSON
Gunnar: I think choice will influence whether we try to line up with similar get/set methods
MagnusF: we will have that a future consideration
move call 1 hour earlier
https://github.com/GENIVI/vehicle_service_catalog/blob/master/seats-service.yml
Ted: we also discussed digital key and trunk delivery
Glenn: there was an SAE
interaction report that might be handy, use cases included are
ECU OTA updates, dynamic platooning, reset of vehicle
infotainment, car sharing including remote key, disabling ICE
of hybrid in restricted zones for emissions and noise control
zones
... geofencing, change of parameters to meet regulatory
compliance
... remote diagnostics and self-check
Gunnar: remote key is currently focus of CCC
Ted: agree, we don't want to compete and they're already shipping but compliments to that such as clearing personal data on ivi
Gunnar: traditional diagnostics, there may be some we want to include and complement VSS
Ted: any others? if not then we can maybe delve down on geofencing
Glenn: I'll need to look,
including switching from imperial to metric in crossing border
from US to Canada
... could also be as vehicle is traveling through different
states, for instance if speed limit is higher in a different
jurisdiction to change that
Gunnar: if I may guess further, I
was thinking of emissions but the technology isn't there
... engine could recalibrate for different emissions
... lower power
Glenn: there is a qualification
with EPA where emissions over the air is considered equivalent
of going into station for emission testing
... remote testing
Ted: those truck weigh stations doing far more than weighing
Glenn: certainly. strong need to
be able to check and ensure vehicle is safe without human
(mechanic) interaction
... including rentals not coming back to depot before going out
again
Ted: regulation and revenue are the strongest motivators in automotive, I could see regulators extending ELD & RFMS further and needing function calls in addition to raw signals
Glenn: tachograph is the EU
version of ELD on driver log data
... RFMS is connecting to heavy trucks in EU for dynamic
data
resolved to collect use cases on wiki
agenda candidates for next week
Gunnar: Steven, can you check on tooling for service catalog yaml parsing?
Steven: people were reassigned,
more review before opening additional code up
... I'll keep it on my radar
Gunnar: if there is blockage, we can discuss what the tools can do and create from scratch
[adjourned]
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/@@tachograph and ELD/Ted: regulation and revenue are the strongest motivators in automotive, I could see regulators extending ELD & RFMS further and needing function calls in addition to raw signals/ Succeeded: s/remote fleet management system/Glenn: tachograph is the EU version of ELD on driver log data/ Succeeded: s/Glenn: that is/Glenn: RFMS is/ Succeeded: s/@@align somewhat with Gen2, formats.../we want to potentially align to the extent possible RPC with Gen2 where we are also considering binary formats in addition to JSON/ Present: Ted MagnusF Ulf Steven Daniel Jon Joakim Peter Glenn Adnan Found ScribeNick: ted Found Scribe: Ted Inferring ScribeNick: ted Agenda: https://lists.w3.org/Archives/Public/public-automotive/2020Sep/0020.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]