- From: Paul Boyes <pb@opencar.com>
- Date: Thu, 10 Apr 2014 23:26:32 +0000
- To: Lucinda Lewis <cindy.lewis@me.com>
- CC: "Rees, Kevron" <kevron.m.rees@intel.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
- Message-ID: <2EDDC796-6B9F-48BD-9E3D-E6C959908662@opencar.com>
The Vehicle Web API could mention that OBD-II could be used as a source, but IMO, the spec should not actually get into the implementation. There is nothing stopping someone from hooking up a bluetooth obi-ii dongle and using this API. Paul J. Boyes -------------------------------- Mobile: 206-276-9675 Skype: pauljboyes On Apr 10, 2014, at 4:11 PM, Lucinda Lewis <cindy.lewis@me.com<mailto:cindy.lewis@me.com>> wrote: Kevron, You asked... What are the implications to developers if OBD-II is the source for VIN? There is a much larger pool of potential customers if OBD-II is the source for VIN. Cindy Lewis On Apr 10, 2014, at 5:52 PM, Rees, Kevron wrote: On Thu, Apr 10, 2014 at 11:50 AM, Lucinda Lewis <cindy.lewis@me.com<mailto:cindy.lewis@me.com>> wrote: Hello there, Following up on your explanation to Andy with some additional questions: * If VIN numbers will not be available, will the API return "Security"? Depends on the implementation. If the implementation decides that the web app doesn't have security rights to VIN, then yes. Otherwise, it could return any of the other options. * Some vehicles have VIN data that is only available through OBD-II. What will you return in this case? The API does not care where the data originates from. If it is supported from any source (CAN, OBD-II, hardcoded in the headunit itself, etc), then the API will return "supported" or some other error (ie "not_supported"). * Also, for those vehicles that only have VIN data through OBD-II, I propose that a note be added to 6.2 of the spec pointing this out. What are the implications to developers if OBD-II is the source for VIN? Thanks, Kevron Cindy On Apr 9, 2014, at 3:38 PM, Rees, Kevron wrote: The purpose of the availability API additions is to allow developers to not only determine if a particular data is supported, but also tell them exactly why it isn't supported. It also handles the scenario that if an attribute is not available at the moment, applications can be notified when the attribute becomes available. enum Availability { "available", "not_supported", "not_supported_yet", "security", "policy", "other" } partial Interface VehicleInterface { Availability available(); short availabilityChangedListener( AvailableCallback callback ); void removeAvailabilityChangedListener( short handle ); } Example 1: if( ( var a = vehicle.vehicleSpeed.available() ) === "available" ) { // we can use it. } else { // tell us why: console.log(a); } Example 2: var canHasVehicleSpeed = vehicle.vehicleSpeed.available() == "available"; vehicle.vehicle.availabilityChangedListener( function (available) { canHasVehicleSpeed = available == "available"; }); ... if(canHasVehicleSpeed) { vehicle.vehicleSpeed.get().then(callback); } -Kevron
Received on Thursday, 10 April 2014 23:27:01 UTC