Re: Proposal for Remote Procedure Call extensions to VISS.

Magnus,


That kind of looks like as if the signal and the RPC are entirely
unrelated and hence could be conflicting unless that is desired as such
to limit what the RPC call can do. In this case, for instance, the
min,max value for the signal and the RPC call could be different. That
could make sense if one would, let's say, want to prohibit how much the
RPC call can open the window by setting min to a value greater than the
corresponding value in the signal spec. However, I would consider that a
corner case. I think it would get more confusing if signal spec and RPC
spec have different data types and units.


My suggestion would be to reference the signal in the RPC call as part
of the argument. That would also allow an RPC call to actuate multiple
items with a single call:


# RPC to actuate window position
- SetPosition:
  type: rpc
  description: Move the window to a spcific position
  arguments:
    - TargetPosition:
      signal: window.position

    - Result:
      datatype: uint8
      description: The result code (from a standard set of result codes)

    - CurrentPosition:

            signal: window.position


:rjs



On 2/10/20 1:52 PM, Magnus Feuer wrote:
>
> Ulf,
>
> The idea is that the function name, and its arguments, live outside
> the VSS spec, driving our JLR principle of "RPC to actuate. Signal to
> sense". We are using a separate YAML file format for our service
> specifications.
>
> That said, the idea of integrating function names into the VSS spec is
> probably worth exploring, although it may be too much feature packing
> into a single spec.
>
> An RPC call in a VSS spec file would look something like:
>
> # Signal to report window position
> - Position:
>   datatype: uint8
>   type: sensor
>   min: 0
>   max: 100
>   unit: percent
>   description: Window position. 0 = Fully closed 100 = Fully opened.
>
>
> # RPC to actuate window position
> - SetPosition:
>   type: rpc
>   description: Move the window to a spcific position
>   arguments:
>     - TargetPosition:
>       datatype: uint8
>       min: 0
>       max: 100
>       unit: percent
>       description: The target position to move the window to. 0 =
> Fully closed 100 = Fully opened.
>   return:
>     - Result:
>       datatype: uint8
>       description: The result code (from a standard set of result codes)
>
>     - CurrentPosition:
>       datatype: uint8
>       min: 0
>       max: 100
>       unit: percent
>       description: The position of the window at the start of the
> window move
>
> Complex arguments (structs and nested structs) would look much like a
> signal tree.
>
> Thoughts?
>
> /Magnus F.
>
>
>
> -------------------
> /System Architect Manager/
> *Jaguar Land Rover*
>
> *Email*: mfeuer1@jaguarlandrover.com <mailto:mfeuer1@jaguarlandrover.com> 
> *Mobile*: +1 949 294 7871
>
>
>
> 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:* Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> *Sent:* Monday, February 10, 2020 02:20
> *To:* Magnus Feuer <mfeuer1@jaguarlandrover.com>
> *Cc:* public-automotive@w3.org <public-automotive@w3.org>
> *Subject:* Re: Proposal for Remote Procedure Call extensions to VISS.
>  
> Hi,
>
> I think this could be an interesting extension to the standard. 
> At the same time I see it as a "wrapper" on the standard, which I do
> not think should be part of the normative standard, possible a
> non-normative note or the like. 
>
> I have a few comments on what is presented
> on https://github.com/PDXostc/viss-rpc.
> - In "subscribe" calls the path is explicitly used, while in "call"
> calls this is implicit in the "function" parameter (which must then by
> the receiving server be mapped to a path). This means every leaf node
> in the tree would have to have a unique function value.
> - In the "call" example the "arguments" filed contain the format of
> provided data. This format is known already by the server from the VSS
> metadata of this node. Providing it in the call open for the problem
> of mismatch with the metadata in the tree. 
>
> I do not think that neither this nor WAMP, or any other pub-sub
> solution, should replace HTTP and/or WebSocket as transports, but
> rather complement them. 
>
> BR
> Ulf
>
> On Fri, Feb 7, 2020 at 12:45 AM Magnus Feuer
> <mfeuer1@jaguarlandrover.com <mailto:mfeuer1@jaguarlandrover.com>> 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.  
>     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.
>
>     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. 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.
>
>     Regards,
>
>     /Magnus F.
>
>     -------------------
>     /System Architect Manager/
>     *Jaguar Land Rover*
>
>     *Email*: mfeuer1@jaguarlandrover.com
>     <mailto:mfeuer1@jaguarlandrover.com> 
>     *Mobile*: +1 949 294 7871
>
>
>
>     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.
>
>
>
>
> -- 
> Ulf Bjorkengren
> *Geotab*
> Senior Connectivity Strategist | Ph. D.
> Mobile  +45 53562142
> Visit  www.geotab.com <https://www.geotab.com/>
>
>  
>
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700