Re: The necessity of the Availability API

The objective of introducing the Availability API is as you stated it. Implementations may differ, though at this point I see no advantage in bulk-retrieving availability info into tables instead of using APIs to retrieve it as-needed. 

In the end, these things are a matter of personal preference, and mine goes with the proposal as it stands. What is important for OEMs is that this functionality is supported, specific approaches achieving it are secondary


________________________________
 From: "Konopelko, Pavel (P.)" <pkonopel@visteon.com>
To: Vadim Draluk <vadim@draluk.net>; "Rees, Kevron" <kevron.m.rees@intel.com> 
Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org> 
Sent: Friday, August 8, 2014 3:35 AM
Subject: RE: The necessity of the Availability API
 

Vadim, Kevron,

Vadim Draluk wrote on 2014-08-08:
> When we are talking about W3C patterns, I believe that current APIs
> taken without Availability match it reasonably well. There is one error
> code that signifies lack of data availability. If app developer decides
> to stop right there, no pattern will have been violated. However, if the
> business logic dictates treating restricted APIs differently, for
> example, going into a screen suggesting subscription (or whatever else
> is dictated by business needs), there will be means to do it.
> 
> As I stated before, Automotive is different because, for now, it is the
> only domain [I can think of] that has specific interest in controlling
> access to some sensors' data. It is likely not to be the last, but at
> this point it is paramount for GM and other OEMs whose position I'm
> familiar with to have this API-level control of sensitive data access.
> Thus I will not support removing this functionality, and will insist on
> keeping it.

So the requirement would be to provide each application with the information about (1) what sensor data are acquired in the vehicle and (2) what of these data have not been made available to the application and for what reason--correct?

> As far as attribute-level vs. interface-level, we can have some
> flexibility there. However the interface-level approach seems to be
> crumbling generally, as the other discussion initiated by Paul (the
> unknown values) appears to show. So there seem to be ample reasons,
> while possibly keeping interfaces as a logical grouping mechanism, put
> significantly more emphases on attribute-level behaviors

Given the above assumption on the requirements I would expect that the application would separate the logic of evaluating whether it has access to a particular signal/attribute when installed on a given system from actually querying and evaluating the signal/attribute value.

A simplistic solution to the Availability API could be then to attach it to the Vehicle object and to have it return simply a list of attributes that fall into each category of availability (e.g. available, not available to the application, not available in the vehicle).  This would reflect the availability due to vehicle configuration and/or licensing and enable the application to react appropriately.

At the access level for individual attributes, the nullable pattern can still be used to indicate that the value is not available for whatever reason.  In particular, the fact that the attribute is listed as 'available', but its value is currently reported as null could be interpreted as an intermittent failure (i.e. 'unknown' or 'error state').


Regards,
--Pavel Konopelko




> From: "Rees, Kevron" <kevron.m.rees@intel.com>
> To: Vadim Draluk <vadim@draluk.net>
> Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
> Sent: Monday, August 4, 2014 10:14 AM
> Subject: Re: The necessity of the Availability API
> 
> 
> Inline
> 
> On Thu, Jul 31, 2014 at 10:03 AM, Vadim Draluk <vadim@draluk.net> wrote:
>> Kevron,
>> 
>> as you might have expected, I'm not thrilled with the proposal.
>> 
>> Whatever the existing W3C patterns, I do firmly believe that automotive
>> presents a set of business cases substantially different from that of
>> desktop, mobile and alike. The main difference is in OEM-proprietary
>> sensors which are considered to provide valuable (that is, monetizable)
>> information to applications. So OEMs have much at stake here with
>> ability to control and/or license access to this information. Having
>> visibility into OAA dealings, I can assure you that this is not a
>> position unique to GM.
>> 
> 
> Thank you for explaining to me this aspect.  However, I'm still
> confused as to why an OEM wouldn't be able to use the existing W3C
> pattern to control access.  Is the idea that the availability API
> would indicate to developers that a particular property is supported,
> but only through licensing?  If so, it seems more appropriate that
> documentation provided by the OEM should indicate this.  I don't see
> the value of knowing this at runtime unless there is some way for the
> user to do something about it (in-app purchase-like functionality?).
> 
> 
> 
> 
>> You are correct when stating that some developers may not care and may
>> not use this API, but others will want to act differently, depending on
>> whether a particular signal is not available because it is not
>> supported on the vehicle, blocked for security reasons or restricted
>> out of business considerations. For such developers the API is
>> necessary, and for OEMs expressing this functionality is paramount.
>> 
>> At the same time, I agree that availability changes is not something of
>> critical importance or of much use, so this part of the API can be
>> removed.
>> 
>> Hope for your understanding of this OEM perspective
>> 
>> Cheers
>> 
>> Vadim
>> 
>> 
>> 
>> ________________________________
>> From: "Rees, Kevron" <kevron.m.rees@intel.com>
>> To: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
>> Sent: Thursday, July 31, 2014 9:46 AM
>> Subject: The necessity of the Availability API
>> 
>> I'm continuing this previously private conversation on the public list.
>> 
>> The argument has been made that if there is to be an availability API,
>> that it should be at the attribute level.  Further, it has been argued
>> that it can only be at the attribute level.  It is not useful at the
>> interface level.
>> 
>> I agree with the argument.  However, I question the premise: that the
>> availability API is necessary at all.
>> 
>> To sum up my rationale, I'll make a couple arguments:
>> 
>> 1 - The pattern is new to the W3C and overrides existing patterns
>> 2 - availability adds unnecessary complexity to the API and developers
>> might not use it
>> 
>> 1 - The availability API is an alien pattern to the w3c.  Attributes
>> on interfaces are typically marked with "?" (nullable mark) to imply
>> availability.  Take the geolocation API as an example[1]:
>> 
>> interface Coordinates {
>> ...
>> readonly attribute double? altitude;
>> ...
>> };
>> 
>> 
>> "The altitude attribute denotes the height of the position, specified
>> in meters above the [WGS84] ellipsoid. *If the implementation cannot
>> provide altitude information, the value of this attribute must be
>> null*." (emphasis mine)
>> 
>> 2 - Given that we already make liberal usage of the nullable marker
>> (?), with the availability API we have effectively multiple ways of
>> discovering whether or not an attribute is provided.  Developers who
>> are accustomed to w3c patterns will likely use the former method and
>> ignore the availability API.  None of the applications we have in
>> Tizen at the moment will use the availability API.  It's hard to say
>> if application developers will use it or find it useful given the
>> already established pattern.
>> 
>> Possible objections:
>> 
>> "The Availability has advantages over the w3c pattern: it helps
>> developers understand why an attribute is unavailable."
>> 
>> I don't think we have a well-established use-case that justifies this
>> pattern.  Developers might only care if it's available or not and may
>> not care why.  We need to establish a better use-case if we want to
>> 
>> "It also notifies developers if that availability changes."
>> 
>> It is true a system *could* change the availability of an attribute
>> for numerous perceivable reasons.  This is true.  However, unless we
>> have a concrete example of a system that does this today or will in
>> the future, we are coding in assumptions that may never be realized.
>> 
>> 
>> I propose eliminating the availability API altogether and using "?" to
>> connotate availability as established by other w3c specifications.
>> 
>> Comments welcome,
>> Kevron
>> 
>> [1] - http://dev.w3.org/geo/api/spec-source.html
>> 
>> 
>> 
> 
> 
>