RE: Vehicle Information API Draft Now Published

Thanks for the comments, Kevron, please see some responses below



-----Original Message-----
From: Rees, Kevron [mailto:kevron.m.rees@intel.com]
Sent: Friday, May 23, 2014 9:01 AM
To: Vadim Draluk
Cc: Paul Boyes; public-autowebplatform@w3.org; internal-autowebplatform@w3.org
Subject: Re: Vehicle Information API Draft Now Published



A few comments about the doc:



About VehicleInterface...  While I agree that certain values are unlikely to change in a typical setup, I'm not convinced they will never change in any setup.  Take for example a use case where I take my vehicle-aware smartphone from one vehicle to the other.  If these values do not indicate to the app they have changed, the user will have to close the app and restart it.  Do we want to support this type of use-case?  I defer to the wisdom of the group.  It's also possible to mark the subscribe, unsubscribe and set as nullable types indicating that they may not always be available depending on the attribute's characteristics.



I do not believe the use case you described above should at all be supported. Subscription should be for changes within one vehicle anyway, even if the runtime is executed in a mobile device. And I do not believe that the scenario as described should require an app restart: if we decide to support mobile platforms and off-board runtimes, we will have to add APIs around the Vehicle interface, allowing for multiple instances of such, and introducing notions of “available” and “unavailable”, all of which will be mobile-specific



I don't have a huge problem with being more specific in the types of access interfaces we use.  Let me know what the group decides and I'll make the change if any.



Your Availability and identification recommendations makes sense to me.



-Kevron



PS.  If possible, I'd prefer these types of discussions to happen directly in email rather than via an attachment.  It's easier for me to inline comments in emails.



Understood, will do as directed







On Thu, May 22, 2014 at 9:11 PM, Vadim Draluk <vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>> wrote:

> Team,

>

>

>

> Attached please see some material for discussion in today’s meeting

>

>

>

> Cheers

>

>

>

> Vadim

>

>

>

> From: Vadim Draluk

> Sent: Monday, May 19, 2014 6:15 PM

> To: 'Paul Boyes'; public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>;

> internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>

> Subject: RE: Vehicle Information API Draft Now Published

>

>

>

> Team,

>

>

>

> Below please see some questions and thoughts on new documents, mostly

> to be considered as something to discuss at our F2F.

>

>

>

> 1.      The Vehicle Information API paper

>

>

>

> Security. I’ve had some extensive written and verbal discussions with

> Dave Ragget, chair of the Apps WG that is covering security. My

> impression is that the group is right now focusing on defining a

> common security model specifically for Web apps, not necessarily

> embedded ones (where they believe there’s little chance to reach a

> consensus between existing platforms). This is the opposite of at

> least GM priorities, which are right now firmly with variations of the

> embedded variety (including ones running in the IVI unit and, albeit with lower priority, ones deployed in mobile devices).

>

>

>

> Hope we have time to talk about it during our F2F. We will probably

> have to settle for some wording that delegates permissions to two

> layers above, the JS app FW layer (Tizen, QNX, whatever else) and the

> OS layer (after all, permissions have to be generated into, say,

> Android manifest, and these are likely to be based on ones defined for underlying native functions).

>

>

>

> Availability. I think the current proposal is quite good as it stands now.

> I’d like to clarify couple of things, such as:

>

> -        Do we need a return code indicating that user consent dialog has to

> be displayed? Not saying it’s really required, as it can be made part

> of the implementation as APIs are asynchronous – still would like to

> talk it through

>

> -        Do all the “negative” codes in Availability correspond to

> permission_denied in VehicleInterfaceError?

>

>

>

> 2.      The Vehicle Data doc

>

>

>

> UnitsOfMeasure. The interface does not fully reflect the proposal I’ve

> written up and adjusted according to quite a few comments I have received.

> It is missing quite a few units that are in the proposal. Elsewhere in

> the document I only see SI-based values returned. So looks like this

> interface is not completely incorporated into the doc in its full and

> most comprehensive form

>

>

>

> DriverIdentification. IMO this one has to be substantially

> generalized. Key fob is only one method of identification, and there

> are already other methods deployed, announced or implemented: face

> recognition, Bluetooth, eventually fingerprint and whatever else. A

> good overall approach would be to separate ID type (one of the above)

> and the actual ID whose semantics is determined by the type.

>

>

>

> TransmissionConfiguration. Should “dsg” not be a separate value if

> “cvt” is one?

>

>

>

> TripMeter. Is there an event that resets the trip meter? If so, it

> would be meaningful to have an API that supports callback upon this

> event, so that apps can do their own adjustment.

>

>

>

> TransmissionMode. Should we account for modes like “Sport”, “Winter”

> and such?

>

>

>

> CruiseControlStatus. Should apps be able to subscribe to “+” and “-“ events?

>

>

>

> DeadReckoning. Looks too low-level to be exposed to apps, usually

> calculated into location info, often in a separate ECU, not available

> to IVI at all

>

>

>

> Odometer. Many vehicles have support for at least two parallel trip

> counters – should we account for that?

>

>

>

> Tire. How does one get readings for a specific tire? Not saying it’s

> not there, just can’t find it. Or is it Zone-based? If so, should be

> made explicit

>

>

>

> DriveMode. This one looks very confusing. Not clear whether it

> pertains to transmission or suspension, and looks like it has

> components of both (“comfort” looks like a suspension setting, “sport”

> can apply to either one whereas “eco” looks very much like

> transmission related. Not sure what “manual” has to do with any of it).

>

>

>

> VehicleSound. Wondering what can one do with

> engineSoundEnhancementMode, especially given that it’s marked as

> OEM-specific from the get-go

>

>

>

>

>

> From: Paul Boyes [mailto:pb@opencar.com]

> Sent: Friday, April 25, 2014 9:33 AM

> To: public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>

> Cc: Vadim Draluk

> Subject: Vehicle Information API Draft Now Published

>

>

>

> The Vehicle Information API draft is now published in the reports

> section

> here:

>

>

>

> http://www.w3.org/community/autowebplatform/


>

>

>

> Please review and send your questions and comments to the group.

>

>

>

> Thanks to everyone who has helped get the specification to this point.

>

>

> Paul J. Boyes

>

> --------------------------------

>

> Mobile:   206-276-9675

> Skype:  pauljboyes

>

>

>

>

>

>

>

>

>

> Nothing in this message is intended to constitute an electronic

> signature unless a specific statement to the contrary is included in this message.

>

> Confidentiality Note: This message is intended only for the person or

> entity to which it is addressed. It may contain confidential and/or

> privileged material. Any review, transmission, dissemination or other

> use, or taking of any action in reliance upon this message by persons

> or entities other than the intended recipient is prohibited and may be

> unlawful. If you received this message in error, please contact the

> sender and delete it from your computer.


Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.