Re: Proposal for Remote Procedure Call extensions to VISS.

Gunnar,

Thanks for the frank and constructive feedback. If we are in agreement that WAMP is the way to go then I will dig into that.

I'll read up on WAMP, explore some of the code and get back to the list.

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: Gunnar Andersson <gandersson@genivi.org>
Sent: Thursday, February 6, 2020 16:40
To: Magnus Feuer <mfeuer1@jaguarlandrover.com>; public-automotive@w3.org <public-automotive@w3.org>
Subject: Re: Proposal for Remote Procedure Call extensions to VISS.

Magnus, my friend

On Thu, 2020-02-06 at 23:44 +0000, Magnus Feuer wrote:
> All,
>
> We have been exploring an extended VISS protocol that allows for
> remote procedure calls to be invoked over the same websocket that
> today runs signal pub/sub.

No... Just no!

I ask you to reconsider this madness, and be reminded (as I
have done repeatedly) that there exists a specification that has put
considerable time into its development to be complete and correct, and
which *also* already has a lot of software written that should not be
reinvented from scratch:

https://wamp-proto.org/_static/gen/wamp_latest.html

> Since we believe this extension may be of use to the wider community,
> we would like to explore the possibility of expanding the W3C
> standard accordingly.

I'm really surprised by this...   I was certain that JLR (I mean not
only the large car OEM but specifically people close to you in your
office/organization) was well aware of the WAMP protocol, since we
discussed it quite a lot before during the time VISS was being
developed.  In some sense it may have been "discovered" by us just a
little bit late because VISS specification had already been developed
to a large degree, but after that, how can this still be the case?

Rather than extending the VISSv1 websocket protocol which is unique to
this specification only, for generation 2 I am becoming more and more
convinced, and I am ready to advocate for, switching to WAMP entirely!
for the WebSocket portion of the specification.  (REST part of protocol
is still independent).

> The proposal, and a working sample implementation, can be found at:
>
> https://github.com/PDXostc/viss-rpc
>
> All is open sourced under MPLv2.
>
> This is in no way a completed spec.

Whereas WAMP is for all extents and purposes a completed spec for all
the features we are talking about _and_ for additional features (e.g.
routed RPC), and for future ideas in their version 2.

> Things such as nested arguments
> (structs) and callbacks missing, so questions, proposals, and
> criticism would be much appreciated.
>
> If we come to an agreement that this is the right way forward I will
> make sure that JLR matures code and documentation as needed to
> integrate them into the W3C standard.

Again sorry for my bluntness but I think that sounds like a huge waste
of time.  There are so many open-source WAMP implementations [2] that
would be a starting point instead, and that would surely benefit from
any available engineering hours for maturing code.

Finally, of course, if your investigations have discovered something
really new and useful, I'm sure the WAMP development ecosystem would be
interested in what you learned!   Because the spec is (re)opened for
future changes and there has been a *lot* of thinking on that side
already about all of this.  Reading about their future ideas they are
far more advanced in their thinking about advanced features for a
messaging middleware of this type.

Sincerely,
- Gunnar

[1] A short(er) overview
https://en.wikipedia.org/wiki/Web_Application_Messaging_Protocol
[2] Implementations: https://wamp-proto.org/implementations.html
[3] Master branch of official spec (in W3C format, even! :)
https://wamp-proto.org/_static/gen/wamp_latest.html
[4] Overview docs https://wamp-proto.org/spec.html