Re: Issue 72 - Getting Closure

Hi,

'Couple' of points to add to the discussion :-)

*i) How does the client inform the server (vehicle) that it no longer wants
to receive notifications. The current spec. version has an unsubscribe
method to do this. In the new proposal, client subscribes for a period of
time but this is more complex to implement on client e.g may need timers to
determine when to resubscribe, important events could be missed if client
does not resubscribe in time.*

Suggest that being able to inform server that clients have ceased to
subscribe is important because server implementation will otherwise waste
processing cycles and memory to prepare and send notifications that are
then ignored


*ii) Is there benefit in creating an abstracted model of a vehicle and its
components or better to treat it as simply a collection of sensors?*

Believe that there _is_ a benefit in creating an abstracted model of a
vehicle - as it is generally easier to write and maintain code using
objects compared with using a much flatter API where client developers must
select from a large list of possible sensors (that will vary from
implementation to implementation).

The object based approach also enables vehicle implementers to encapsulate
related information and return it in single object instance e.g for
multiple signals that relate to same real world event or measurement
period. It also gives implementers more of an opportunity to create
abstractions that can later be modified internally as long as the changes
do not break the interface contract. A real world analogue is a manual
gearbox. An implementer is completely free to change internally how the
gearbox actually works as long as they do not change the external interface
(gear lever, input/output shafts)

Suggest that unless there is a benefit in modelling a vehicle to define the
attributes and behaviours that it has in common with other vehicles (and in
so doing, make it easier for developers to work with vehicles) as distinct
e.g. from working with . heart rate monitors), I don't see the
justification for having a separate Vehicle API specification that is
essentially an example implementation of the Sensor API.

However, if we went down that route, I would suggest that it is likely that
one or more proprietary higher level Vehicle APIs would emerge that wrapped
the Vehicle Sensor API in a way that abstracted e.g. engine sensors into an
engine 'class' or 'type', gearbox sensors into a gearbox type etc in order
to make client code easier to write and maintain.

Apologies that this mail has become a little long, but hope the above is a
helpful contribution to the discussion :-)

Best wishes 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 9 February 2016 at 08:59, Dave Jensen <david@jensen47.com> wrote:

> I like the idea of something that is Websocket-ish/RESTful-ish.
>
> I don't know if this was where you were going but I think using URIs, or
> topics, could be a lot more extensible than rigid interfaces. It could even
> go so far as to allow providers of the API to create their own extensions
> to the API. e.g., an event for "self-driving" mode being enabled/disabled.
>
>
> On Tue, Feb 9, 2016 at 12:12 AM, Tobie Langel <tobie@codespeaks.com>
> wrote:
>
>> Updated the Event-based example to explain it better and answer the
>> pending questions.
>>
>> That said, I feel like it's seriously worth considering a lower level
>> WebSocket-ish/RESTful-ish API + JSON schema (or JSON-LD) on top of which a
>> JavaScript API could be specified or simply built and open-sourced This
>> follows the precepts of the Extensible Web Manifesto[1] and is the desired
>> way to build modern specs. It's also very much inline with the suggestions
>> of the TAG.
>>
>> Such a solution would:
>>
>> - come with authentification built-in.
>> - enable current usecases (infotainment system),
>> - open-up a slew of more advanced usecases (cars communicating to sync,
>> e.g. in convoys, pushing the data to the cloud for analysis, etc.),
>> - have an architecture similar to that of Web of Things (and could
>> probably be designed to be compatible with it).
>> - be very easy to extend.
>>
>> Best,
>>
>> --tobie
>>
>> ---
>> [1]: https://extensiblewebmanifesto.org/
>>
>> On Tue, 9 Feb 2016, at 05:18, Paul Boyes wrote:
>>
>> Here is my quick attempt at summary of many of the issues raised in Issue
>> 72:
>>
>> *Main Issue:*
>>
>>    - DOM Events as opposed to or in addition to  subscriptions
>>    - ondata versus subscribe
>>    - on change versus subscribe
>>
>>
>> *AdamC’s Summary of Main Issue:*
>>
>>    - Dedicated handlers for each property
>>    - vehicle.trip.onaveragespeedchange
>>       -
>>       - I don’t believe this will work in the case of setting a specific
>>       signal. You would have to have separate attribute for set and onchange
>>       which would get confusing.
>>       - Generic observers
>>    - vehicle.trip.averageSpeed.onchange
>>       -
>>       - May create lots of edge cases
>>       - Specific observers
>>    - vehicle.trip.averageSpeed.onaveragespeedchange
>>       -
>>       - Dramatically increase the quantity of APIs on vehicle
>>       - Existing pub sub
>>    - Not considered web friendly
>>       -
>>       - Inconsistent with other web technologies
>>
>> *Urata-sans Summary with Pros and Cons:*
>> https://github.com/w3c/automotive/wiki
>>
>> *Ancillary Issues:*
>>
>>    - complexity of zone
>>    - suffixing interfaces
>>    - Vehicle versus Sensors
>>    - Web socket or REST calls to expose vehicle data
>>    - Units
>>
>>
>>
>>
>> Talk with you all tomorrow.
>>
>>
>>
>>
>>
>> Paul J. Boyes
>> --------------------------------
>> Mobile:   206-276-9675
>> Skype:  pauljboyes
>>
>>
>>
>>
>>
>>
>
>