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

Re: Issue 72 - Getting Closure

From: Tobie Langel <tobie@codespeaks.com>
Date: Tue, 09 Feb 2016 09:12:52 +0100
Message-Id: <1455005572.2324211.515936170.0EC4F31A@webmail.messagingengine.com>
To: Paul Boyes <pb@opencar.com>, Adam Abramski <adam.m.abramski@intel.com>, Dave Jensen <david@jensen47.com>, Kazuyuki Ashimura <ashimura@w3.org>, Natasha Rooney <nrooney@gsma.com>, ted@w3.org, "Crofts, Adam" <acrofts1@jaguarlandrover.com>, Jeff Payne <jp@opencar.com>, 刘大鹏(鹏成) <max.ldp@alibaba-inc.com>, "Adolph, Martin" <martin.adolph@itu.int>, "Gavigan, Kevin" <kgavigan@jaguarlandrover.com>, Shinjiro Urata <Shinjiro.Urata@access-company.com>, public-automotive@w3.org, kevron.m.rees@intel.com, Peter Winzell <peterwinzell.gbg@gmail.com>
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
>
>
>
Received on Tuesday, 9 February 2016 08:53:17 UTC

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