Re: The necessity of the Availability API

Kevron,

sorry for a late reply, currently in Asia, and quite busy with ongoing stuff.

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.

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

Cheers

Vadim


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