Re: The necessity of the Availability API

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.

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