AW: Proposal for Remote Procedure Call extensions to VISS.

Hi Gunnar,

To be clear, my earlier enthusiastic message was about the need for a robust RPC mechanism, not about a specific way to implement it. And I stand by it :)

Being a little late to this party, I have never heard about WAMP (an acronym which unfortunately a bit overloaded....), but I am reading up on it know.

Do I understand it correctly: Your idea would be use WAMP as "protocol"/technical scaffolding, at least for the websocket part and just figure a way how to put the VSS data model behind it (e.g. defining some standardized CALLs such as viss.get / set that should be implemented on top of WAMP)?

No opinion expressed here (I am missing data :) ),  just want to make sure, I understand it correctly.



Mit freundlichen Grüßen / Best Regards

Sebastian Schildt 
CR/AEX1
Threema / Threema Work: T8YWYXJ9

> -----Ursprüngliche Nachricht-----
> Von: Gunnar Andersson <gandersson@genivi.org>
> Gesendet: Freitag, 7. Februar 2020 01:41
> An: Magnus Feuer <mfeuer1@jaguarlandrover.com>; public-
> automotive@w3.org
> Betreff: 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

> 
> 
> 
>

Received on Friday, 7 February 2020 16:25:05 UTC