This page is for the ViWi Task Force to organize thoughts, contrast ViWi and VISS, collect use cases for app development, possible transition and merge plan, etc
This Task Force will send minutes and converse by email over using [ViWi] Subject tag on email@example.com
- Ted Guild
- Paul Boyes
- Rudolf Streif
- Patrick Lünnemann
- Wonsuk Lee
- Kevin Gavigan
1st and 3rd Monday of the month
2nd and 4th Monday for PDT in North America, Tuesday in Asia, Europe and EDT North America of the month
Open Discussion Points
- discussion of rest approach as the general, architectural principal [? ViWi is REST + WebSocket, not just REST ?][Should comparison with PSA + IBM, AGL, other approaches also be considered?]
- REST, API, Service, Plugins - Programming, Architectural and Integration paradigms
- necessary scopes for a in-vehicle protocol
- Domains in a vehicle: media, speech, devices, weather, traffic, payments, etc... (See https://www.w3.org/community/autowebplatform/wiki/Potential_Work_Areas)
- Cohesive common access methods and data definition that work across domains. Give the app developer cohesive access
- Common integration layer for application frameworks
- Cross cutting security approaches
Notes pertaining to architecture
@@links to previous TAG discussion, internal W3C Staff architectural minutes
Vehicle Information Service (VIS) and Vehicle Information API (VIA) Use Cases
For the discussion of the ViWi use cases it might also be useful to compare them to the VIS/VIA use cases. VIS/VIA is an evolution from an earlier specification draft detailing access to vehicle information from a browser and/or web runtime running on an infotainment unit inside the vehicle. For that purpose the specification treated the vehicle as a platform similar to a smartphone where APIs built into the browser provide access to platform sensors such as GPS, accelerometer etc. Looking at a vehicle as a platform like that makes sense in general, however, it comes with some major differences:
- a modern car has hundreds of sensors and actuators,
- vehicle hardware and software platforms are diverse.
The typical approach for browser APIs models the APIs and data types in WebIDL as part of the specification. Browser implementers then take the specification and build the API into their browser software. If the browser is offered for different underlying hardware and software platforms (OS) then the implementation has to be ported to each of those platforms. That works well if there are only a few platforms that each have a huge proliferation to amortize the cost of the implementation. It also works best for a small number of sensors and actuators that are mostly consistent across all platforms and do not change or grow significantly.
Vehicle platforms are different: hardware and software platforms are the choice of the automakers and their suppliers and vary significantly not just between automakers but also between models of the same automaker. Implementing APIs directly into the browser software would hence hardly be economical. Vehicles also have many hundreds of sensors and actuators and the number is steadily growing with new features being implemented in cars. A specification trying to capture all and model them as APIs and data types would permanently lagging behind. Actual implementations into browsers would be even more behind as the product cycles of the industry are much longer.
Hence the new VIS/VIA specifications aim to tackle these problems by
- separating the sensor and actuator information from the API - there are only the generic APIs get, set, subscribe and unsubscribe, the information to be accessed is passed as arguments;
- splitting the implementation into a service and a library - a websocket server provides the service that is accessed by applications using the library.
The primary uses cases supported by VIS/VIA are:
- Provide access to vehicle signals such as speed, engine rpm, outside temperature, coolant temperature, battery level, door status, location, etc.
- Provide controls for actuators such as lights, windows, sun/moon roof, etc.
At their inception VIS/VIA did not intend to:
- Provide access and controls for typical infotainment data such as what station is playing, tracks on a media, playlists, etc;
- Provide access and controls for devices outside of the vehicle network boundaries.
However both the ViWi or VISS approaches supports returning object graphs for any domain.
Differences VISS to ViWi
- Filtering for a GET-Request in VISS is not available (VISS Issue #135 has been created to review adding this)
- Wider domain scope within ViWi as in VISS right now (but VISS readily supports returning object graphs for other domains with their own schemas)
- Change multiple elements in one call within VISS
- Use of Sockets
- VISS: One WebSocket
- ViWi: One HTTP Socket + One WebSocket
- Any Advantages in the HTTP Socket?
- Why just use sockets and not rest style sockets
- Decision in Summer F2F 2016?
- VISS spec. would progress according to WG charter. Working Group would look for areas of consensus. ViWi will be picked up by Business Group and will be discussed along with possible proposals from other interested parties e.g. PSA+IBM, AGL.
- New Scopes for VISS
- Media? Tracks, Albums, Playlists
Why to REST?
[Suggest this should be in the form of a table to allow side by side comparison]
- REST allows caching of GET requests [WebSocket: results can also be cached]
- routers, proxies etc. make heavy use of it to speed up the access
- controllable via Etag and If-None-Match Headers
- All entities accessible via HTTP GET are be side-effect free, i.e the entity just returns a representation of itself. Invoking the entity does not result in modifying the entity. [WebSocket: Get requests are also side-effect free]
- Modifications (POST requests) are idempotent by design [WebSocket: Set is idempotent by design]
- heavily promotes multi client capabilities
- Use hyperlinks to reference from entity to entity [WebSocket: Object graph could be efficiently searched/navigated using CSS (jQuery) style selectors]
- Designed to reveal data gradually. No need to reveal all data at once, hyperlinks are used to obtain more details. [WebSocket approach supports either revealing data gradually or revealing more/all data at once]
- allows cross domain and cross host linking [WebSocket: No restriction on how client uses or combines object graphs, in that sense approach is purely data driven]
- REST is easy to implement in client and server [WebSockets are very easy to implement in client and server]
- Even implementations on very small (embedded) devices including those which run in fixed cycles (e.g. 100ms) available
- REST verbs well known throughout the industry
- REST is easy to implement, debug and automatically test with readily available tools [WebSocket: Comparison for ViWi is not REST vs WebSocket, it is Hyrid REST + WebSocket vs WebSocket. Hybrid approach forces code to be split between REST and WebSocket, so probably more difficult to implement, debug and more code to automatically test c.f. pure WebSocket approach]
- Browser Tools
- Server tools
- API Test tools
- REST uses well known standardised Headers
- REST uses query parameters to allow filtering
- lists (even huge lists)
- WebSocket push is just an extension of REST to subscribe to GET urls
- It feels very natural to integrate with other devices (IoT) and Web services => promotes adoption
Pros and Cons
Simplicity: Pure WebSocket model is simpler to implement and maintain than a Hybrid REST + WebSocket approach. In the pure WebSocket model, client code is interacting with a single interface to Get, Set and Subscribe to data. In the hybrid model, the developer has to write separate code to Get a specific signal (using REST) versus Subscribing to receive notifications for that signal (via WebSocket). Developer then needs to add code to combine results to create a consistent state model, creating the potential for race conditions. If values are different, which is the later, the result from the Get or the data in the subscription notification?
Consistency: Getting data via different routes is also prone to logical and temporal inconsistencies. If different mechanisms are used to get and subscribe to data or to get data separately, then how can a client App be sure that data is logically or temporally connected? For example, if a single mechanism is used to e.g. get number of wheel ticks and speed at the same time as part of the same result set, then the server can take care to ensure that the speed value is ALWAYS the processed result that follows from the number of wheel ticks. If a client of a Hybrid system subscribes to get wheel ticks and separately gets vehicle speed, it will be very much harder for the server to ensure that related or corresponding values are returned (e.g. it might have to implement its own cache that it refreshes periodically to do this).
Flexible: WebSocket approach defines only Get, Set, Subscribe, Unsubscribe, Authorize and a 'getMetaData' method. It is completely general and can easily be re-used across different domains, with different endpoints returning data satisfying the relevant schema for that domain.
DRY: A pure WebSocket approach makes it easy to get all or part of an object graph and/or refresh the SAME graph using a subscription. This DOM style, 'in-memory' object graph can be searched and traversed using a CSS selector (jQuery) like approach. Hybrid approach needs to have separate codebases and to continually combine data sources in order to construct a searchable in memory object graph.
Security: A Hybrid approach increases the security attack surface as both RESTful web services and WebSocket need to be secured. In a pure WebSocket approach, only WebSocket needs to be secured.
- REST + WebSocket