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
>
>
>
>
>
>