Re: Draft Specification for Service Based Approach Using WebSockets

Hi Rudi,

Thanks for the feedback, my comments are in blue below.

Client-side Subscription ID
--------------------------------------
The server returns an acknowledgement when a subscription attempt was
successful. The acknowledgement contains a server-side subscription ID and
the subscription parameters so that the client can identify the request. I
suggest for the subscription request to contain a client-side subscription
ID/handle. That would alleviate the client from parsing the subscription
parameters and matching them to the request. That client-side subscription
ID could also be included with the data sent to the client.

Agree that we could do this, but my preference would be for the
subscription id to be server generated (as this is simpler, please see also
answers to other questions). The server can then guarantee uniqueness for
that websocket session. Personally, I don't think it would be too onerous
for client to link the server subscription id to the using the path. In the
real world, if I subscribe to receive a magazine in the post, the publisher
decides what the subscription id is. This follows the same pattern.

Repeated Interval Subscription
--------------------------------------------
The subscribe action in the table does not define what happens when the
client sends repeat subscription messages with different intervals for the
same signal path. Would that result in another subscription or in a change
of the interval of the previously made subscription? I would think that it
should change the subscription interval. However, if we used a client-side
subscription ID and the client uses a different ID for the subsequent
subscription request to the same signal with a different, or essentially
any interval, would that result in a change of the previous subscription
despite the different client ID (eventually with an updated client-side
subscription ID)?

If the client sends multiple subscriptions to the server for different
intervals, then the server would respect the request and create separate
subscriptions with different ids, and use the different id to identify the
response. Slightly unusual case, but for all the server knows, the client
might have a legitimate reason for wanting to see the same signal at
different intervals. Similarly, a client could subscribe using onchange and
interval to obtain data for the same signal. These two requests would
result in two independent subscriptions. This keeps it simple on the server
side. The server just respects the clients wishes.


Repeated Onchange Subscription
-------------------------------------------------
Are repeated onchange subscriptions supported for the same signal but with
different above and below thresholds? One could think of multiple
subscriptions to define bands of engine.rpm: (above: 0, below: 1000),
(above: 1000, below: 2000), ... If that is possible then overlapping
intervals/bands would result in multiple messages?

Yes. This keeps it simple again. If the client wants to create multiple
independent subscriptions, then thist is allowed.

Thanks for the quick feedback, look forward to speaking to you in a few
minutes on the call.

Kind regards,

Kevin

*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 7 June 2016 at 23:58, Streif, Rudolf <rstreif@jaguarlandrover.com> wrote:

> Adam, Kevin,
>
> Thank you for adding this to the wiki (which reminds me that I still have
> to add the VSS details to it).
>
> A couple of questions:
>
> Client-side Subscription ID
> --------------------------------------
> The server returns an acknowledgement when a subscription attempt was
> successful. The acknowledgement contains a server-side subscription ID and
> the subscription parameters so that the client can identify the request. I
> suggest for the subscription request to contain a client-side subscription
> ID/handle. That would alleviate the client from parsing the subscription
> parameters and matching them to the request. That client-side subscription
> ID could also be included with the data sent to the client.
>
> Repeated Interval Subscription
> --------------------------------------------
> The subscribe action in the table does not define what happens when the
> client sends repeat subscription messages with different intervals for the
> same signal path. Would that result in another subscription or in a change
> of the interval of the previously made subscription? I would think that it
> should change the subscription interval. However, if we used a client-side
> subscription ID and the client uses a different ID for the subsequent
> subscription request to the same signal with a different, or essentially
> any interval, would that result in a change of the previous subscription
> despite the different client ID (eventually with an updated client-side
> subscription ID)?
>
> Repeated Onchange Subscription
> -------------------------------------------------
> Are repeated onchange subscriptions supported for the same signal but with
> different above and below thresholds? One could think of multiple
> subscriptions to define bands of engine.rpm: (above: 0, below: 1000),
> (above: 1000, below: 2000), ... If that is possible then overlapping
> intervals/bands would result in multiple messages?
>
>
> BTW, I would love to drive the car from the example with 1200 kW. :) (That
> should actually be engine.power as engine.tps is throttle position with a
> value between 0 and 100).
>
>
> Thanks,
> Rudi
>
>
>
>
> On Tue, Jun 7, 2016 at 6:18 AM, Paul Boyes <Paul.Boyes@inrix.com> wrote:
>
>> Excellent indeed.  I will look at this in detail later today.
>>
>> *Paul J. Boyes* | INRIX | Director of Telematics and Standards - OpenCar
>>  |  206-276-9675 | paul.boyes@inrix.com <bryan@inrix.com> | www.inrix.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.inrix.com_&d=BQMFAg&c=QbuapHRvbn0JdC8vTVkPHg&r=PRAN7lum5Ra662QLho8LU3bhFjBvLXn3bBkFbW0Amjo&m=V5l0WXfOEJwhcE0JsN06mQ5SQhpXL-DuAuK3YcnTZoc&s=OqQVi_DcS5rv8or8hZdFvY0re6YF0Wl-_8okxrxOF0w&e=>
>>
>> On Jun 7, 2016, at 3:56 AM, Peter Winzell <Peter.Winzell@melcogot.com>
>> wrote:
>>
>> Excellent !
>> I have just browsed through – Thank you for your hard work!!
>> /pw
>>
>> *From:* Crofts, Adam [mailto:acrofts1@jaguarlandrover.com
>> <acrofts1@jaguarlandrover.com>]
>> *Sent:* Monday, June 6, 2016 12:58 PM
>> *To:* public-automotive
>> *Cc:* Kevin Gavigan; Peter Virk; Lovene Bhatia
>> *Subject:* Draft Specification for Service Based Approach Using
>> WebSockets
>>
>> Hi All,
>>
>> Kevin and I have drafted a specification for the service based approach
>> using WebSockets, as discussed in Issue 81
>> <https://github.com/w3c/automotive/issues/81>. The draft can be found in
>> the working group wiki here
>> <https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#WebSocket_2>
>> .
>>
>> The specification builds upon the approach raised by Powell Kinney, using
>> a single WebSocket to send JSON data structures to the server. The JSON
>> structure specifies the desired vehicle signal specification (VSS) path, an
>> action parameter to specify get, set, subscribe or unsubscribe as well as a
>> number of optional parameters.
>>
>> This specification allows:
>>
>>    - Use of the VSS, including wildcards and indexing
>>    - GET/SET over WebSocket
>>    - SUBSCRIBE to receive change notifications, allowing settable change
>>    thresholds and upper/lower bounds
>>    - SUBSCRIBE to receive notifications at a given time interval.
>>    - UNSUBSCRIBE via a subscription handle
>>    - UNSUBSCRIBE from all notifications
>>    - Security tokens to be passed from the client to the server, such as
>>    OAuth 2.0
>>
>> We'll go through this on the call on Tuesday night and look forward to
>> hearing your thoughts.
>>
>> Kind regards,
>>
>> Adam
>>
>> --
>> *Adam C**rofts MEng (Hons) MIET*
>> Connected Infotainment
>> Vehicle Engineering
>> Tel: +44 (0) 1926 921607 | 87311607
>> Mob: +44 (0) 7790 094350
>> Desk: G03/054, Building 523, Gaydon
>> Mail Drop: G/26/3, Building 523, Gaydon
>>
>>
>> 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.
>>
>>
>>
>
>
> --
> *Rudolf J Streif*
> System Architect - Open Source Initiative
> Open Source Technology Centre
>
> *M:* +1.619.631.5383
> *Email:*  rstreif@jaguarlandrover.com
>
>
>
> UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR
> US: 1419 NW 14th Ave, Portland, OR 97209
> jaguar.com | landrover.com
> -------------------
> 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.
>
>