W3C home > Mailing lists > Public > public-automotive@w3.org > June 2016

Re: Draft Specification for Service Based Approach Using WebSockets

From: Gavigan, Kevin <kgavigan@jaguarlandrover.com>
Date: Thu, 16 Jun 2016 13:41:50 +0100
Message-ID: <CAKaHsmeiW4_nBa7aLX1F3j26=Kuy-ozMh4wDgX2sPeXt7JMb3g@mail.gmail.com>
To: Peter Winzell <Peter.Winzell@melcogot.com>
Cc: Paul Boyes <Paul.Boyes@inrix.com>, "Crofts, Adam" <acrofts1@jaguarlandrover.com>, public-automotive <public-automotive@w3.org>, Peter Virk <pvirk1@jaguarlandrover.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>, Rudolf Streif <rstreif@jaguarlandrover.com>, Powell Kinney <powell@vin.li>
Hi Peter,

Thanks very much for the feedback and the questions.

*>> In our previous spec through WebIDL we have a way of declaring a
specific signal readonly. Is this still desirable ? *

As you say, certainly agree that it is valuable to mark a signal as readonly

>> Regarding my second comment – after thinking on what you mean a bit
more. I guess that you mean that WebIDL is only used as base to implement a
javascript library outside the actual browser domain ? The purpose of the
WebIDl being just another way of specifying an API on another abstraction
level than the actual javascript library itself.

Indeed. From our perspective there are (at least) two possible ways in
which the Web IDL definition could be used. One would be as you describe
where a browser vendor implements a top level object called e.g. 'Vehicle'
(like Document in the HTML DOM) , the other covers cases where the onboard
web runtime (browser) used by an OEM hasn't done this. So to enable HTML
Apps running in the web-runtime on a vehicle, there is a W3C Automotive
Standards based JavaScript library that exposes the Vehicle and Data (VSS)
APIs to web based clients.

[The benefit of this to OEMs and companies writing Apps to run on vehicles,
is that an App written to run on one vehicle should run on other vehicles
(with no or little change because they use a standard JavaScript library to
get/set/subscribe to vehicle signals). If we don't have this  is a risk
that there will be slightly different implementations e.g.
VehicleSpeed.get() vs vehicleSpeed.Get().

Thanks once again,

Best wishes and 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 16 June 2016 at 10:01, Peter Winzell <Peter.Winzell@melcogot.com> wrote:

> Hi Kevin!
>
>
>
> Getting my head a bit above the “water” I have some time to look at the
> specification draft which you guys so admirably have started on.
>
>
>
> Two comments so far:
>
>
>
> (This first comment  is more related to the data spec I guess)
>
> In our previous spec through WebIDL we have a way of declaring a specific
> signal *readonly*. Is this still desirable ? if so should it be added to
> the data tree ?
>
>
>
> Previous WebIDL ex:
>
> Interface Indentification : VehicleCommonDataType {
>
>                              *readonly* attribute DOMString? VIN;
>
>                              *readonly* attribute DOMString? WMI;
>
>                              …
>
> }
>
>
>
> Would then be something like:
>
>
>
> # Vehicle type specific signals
>
> -          Vehicletype.VIN
>
> type: String
>
> *access: readonly*
>
> description: Vehicle Identification Number
>
>
>
> Second comment is from the Architecture Component Model:
>
> “… This includes a Javascript Library which implements a Web IDl
> definition …“
>
>
>
> I am not sure I understand what you mean here. I would think that what you
> have is a WebIDL implementation of the spec into a WebRuntime such as
> Google Chrome, IE , Opera etc… From my understanding you would branch out
> or use your own browser engine branch, and add the WebIDL and its
> associated native files, and then rebuild the browser engine which then
> would let the Javascript Engine expose the WebIDL based API to the web
> developer (This is how you would do it using Chrome) ?  Could you elaborate
> a bit on what you mean here.
>
>
>
> Br
>
> Peter Winzell
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Gavigan, Kevin [mailto:kgavigan@jaguarlandrover.com]
> *Sent:* Monday, June 13, 2016 10:56 AM
> *To:* Paul Boyes
> *Cc:* Peter Winzell; Crofts, Adam; public-automotive; Peter Virk; Lovene
> Bhatia; Rudolf Streif; Powell Kinney
> *Subject:* Re: Draft Specification for Service Based Approach Using
> WebSockets
>
>
>
> Hi Gents,
>
>
>
> I've updated the wiki spec to include an architecture diagram. It's based
> on the one on the whiteboard at the F2F (but this only showed an onboard
> web client accessing data, so have extended to include other types of
> clients)
>
>
>
> All feedback  or suggestions for improvement very much welcomed of course
> :-).
>
>
>
> With your agreement, we will modify the WebSocket section to include a
> requestId that is passed from client to server on each call and which is
> echoed back in the response (this was an idea proposed Rudi via email and
> by Powell and Rudi on the call which will make it much easier for client to
> link responses to requests)
>
>
>
> Thanks and regards,
>
>
>
> Kev
>
>
> *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 16:36, Gavigan, Kevin <kgavigan@jaguarlandrover.com>
> wrote:
>
> Hi,
>
>
>
> I've updated the Security section to include some general points that
> apply to both WebSockets and RESTful web services:
>
>
>
>
> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations
>
>
>
> 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 14:18, 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.
>
>
>
>
>
>
>
Received on Thursday, 16 June 2016 12:42:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:50 UTC