Re: RPC update

Thank you, Ted.

We had an extended chat about the service catalog topic today, which I tried to summarize below. Please feel free to correct me or add more things that we need to roll into the conversation.

Purpose (distilled from the slide deck below)
To standardize a set of services and their protocols, enabling external entities such as fleet managers, mobile devices, service providers, and other agents to safely and robustly interact with a vehicle.

Requirements
See slide 3 of https://lists.w3.org/Archives/Public/public-automotive/2020Mar/att-0033/W3C_Gen2_Remote_Procedure_Calls.pdf

Roles and responsibilities.
There is a tentative agreement that GENIVI will define the service catalog format and its content while W3C focus on service transport mechanisms, thereby copying the successful setup from the VSS / VISS project.

Protocols
W3C is exploring possible candidates from existing RPC implementation, with a special focus on JSON-RPC and JSON-WSP since they can co-exist with a VISS(2) session on the same websocket connection. Further comments would be appreciated.

FrancaIDL vs. YAML
There is an agreement between GENIVI and W3C to:
- Use YAML as a file format.
- Have the YAML format to be a semantic subset of FrancaIDL.
- Minimize the YAML subset and grow it as needed instead of doing a "big design up front".

Magnus and Gunnar are creating an initial format proposal, backed by validation tools.

RPCs vs. Signals
The initial proposal is to use RPC calls to actuate the vehicle (set tuner frequency, initiate vehicle tracking, etc), and signals to report status (current position, volume change, etc).
RPCs will immediately (within 50-ish msec) return with either a completion code, an error code, or an in-progress code, where further progress information can retrieved via signals.
A transaction concept may needed on top of this in order to track RPC initiation, progress, and completion.

A proposed modification to the strategy above is to use RPCs for complex operations, but have writable signals for simple operations such as setting volume and turning dome lights on/off. An agreement was reached to prototype both solutions to find out which one is most accessible to service & app developers.

Large information retrievals
An unsolved problem is how we do large information retrievals, one use case being a request to pull all available Sirius XM stations with their album art. The reply may be hundreds of kbytes large and need chunking, a separate data channel, or some other delivery mechanism outside the control-plane of RPCs and signals.

Data plane management
In addition to the information retrieval problem above, we also need to solve the general problem of data vs. control plane management, as highlighted by the recent VSS conversation about streaming signals.
A reference use case for RPC is camera management where turning cameras on/off is done over the control plane while streaming their content is done over the data plane.


Regards,

/Magnus F.

-------------------
System Architect Manager
Jaguar Land Rover

Email: mfeuer1@jaguarlandrover.com<mailto:mfeuer1@jaguarlandrover.com>
Mobile: +1 949 294 7871

[https://ci3.googleusercontent.com/proxy/OfaGrHPlawsuQPtTYPlu2XkJRCrzJtHOGv2OSrFHsvJ6km-xYenAYwOsmmC-X18PrWn7LzA6AM--8oIU05Ifg6GD=s0-d-e1-ft#http://www.jaguarlandrover.com/email/jlr.jpg]

Jaguar Land Rover North America, LLC
1450 NW 18th Ave, Portland, OR 97209
-------------------
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a specific individual and purpose.  The information is private and privileged and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, please e-mail us immediately.  We apologise for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.



________________________________
From: Ted Guild
Sent: Monday, June 15, 2020 11:58
To: public-automotive
Subject: RPC update

Magnus and I met toward the end of last week on RPC and have some
thoughts and early inclinations to share. Magnus, do please add
anything I missed or otherwise comes to mind.

Minutes from March virtual f2f on RPC, slides linked from it

https://www.w3.org/2020/03/26-auto-minutes#item05

As discussed RPC API spec likely to reside at W3C and service
catalog of callable procedures could be at GENIVI similar to how VISS
and VSS are split. I would like to engage the broader W3C community
tech companies who have departments interested in connected vehicles
contributing toward a service catalog as well.

We have the start of materials for a spec from JLR in their public
github repo with some related prototype code and other materials in the
repo. We should discuss on an upcoming call reaching internally within
the other OEM and suppliers in the group for a second (or third if I'm
one) editor.

https://github.com/PDXostc/viss-rpc

The vehicle RPC spec should intend to be compatible with VISS and Gen2.
Either VISS/Gen2 should still be the preferred way to confirm change in
signals or check progress (eg window lowering) via signal subscription
after a procedure call.

In dstc sample code, Magnus was using callbacks. In the browser world
and W3C promises are universally preferred to callbacks as non-
blocking, cleaner code especially in nested call situations. This may
not make as much sense in-vehicle if we're dealing mostly with short,
atomic calls compared to wanting several things to render quickly in a
browser while processes are still running. We should keep it simple,
see how widely callback and promises are implemented in RPC library
implementations and delve deeper into what is needed before deciding.

We should avoid recreating RPC which has had so many variations over
the years and find one widely deployed and suitable for our needs,
avoiding some of the crufty vintage ones such as DCOM and CORBA.

https://en.wikipedia.org/wiki/List_of_RPC_implementations

JSON-RPC and JSON-WSP are particularly interesting in the sense we're
already using JSON in VISS and Gen2. Consistency in messaging would be
beneficial. We're interested in hearing experiences people have had
with various RPC implementations and inclination towards using them
here.

https://en.wikipedia.org/wiki/JSON-RPC

--
Ted Guild <ted@w3.org>
W3C Automotive Lead
https://www.w3.org/auto