Re: Vehicle Availability RFC

On Thu, Apr 10, 2014 at 4:26 PM, Paul Boyes <pb@opencar.com> wrote:
> 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.
>

Agreed.  This might actually be the way I'll be testing my implementation of it.

>
> Paul J. Boyes
> --------------------------------
> Mobile:   206-276-9675
> Skype:  pauljboyes
>
>
>
>
> On Apr 10, 2014, at 4:11 PM, Lucinda Lewis <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> 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:40:34 UTC