RE: some general spec feedback for consideration

Comments below.

From: Tina Jeffrey [mailto:tjeffrey@qnx.com]
Sent: Tuesday, April 15, 2014 9:54 PM
To: public-autowebplatform@w3.org
Cc: Marc Lapierre; Nik Schultz; Vadim Draluk (vadim.draluk@gm.com)
Subject: some general spec feedback for consideration

Hello All,

After the F2F, I ask a few of our engineering folks to review the spec as it stands today and provide feedback. In fact, Marc Lapierre and Nik Schultz (on copy) from QNX have recently joined the BG and are now on the mailing lists -  I'm hoping they will become more involved in providing insight as we move towards finalizing this spec.

Here is a summary of their comments:

  *   Everything seems to inherit from VehicleInterface, which provides a set function, although most of these are meant to be read only. I understand that there are readonly flags, but it still seems odd to even offer that functionality if we never expect to enable it, while other interfaces (mostly those that inherit from VehicleCommonDataType) provide read only data that should be writable (ex: most climate control interfaces).
     *   It also seems odd that many interfaces are flat/per-sensor while others are grouped under VehicleCommonDataType objects. Is there a reason we have both types of data? I see is the timestamp, but this could be applicable to either case. The only other item is the zone, however it seems odd to make something not settable only because there is a zone - most zoned things are HVAC related, which are the main things we would want to set.
  *   For the get history conversation: This should be an available feature, but it should not be enabled by default. That excessive amount of logging would be too heavy on the system. We should be able to enable it on a per sensor basis from the javascript API (Ex: sensor.startLogging(), sensor.stopLogging(), sensor.getLogs()). This could also be achieved by the subscribe methods, but the amount of callbacks here could cause performance issues
That seems fair.

     *   As a subnote to this, I would like to see an actual system implementation of this spec to see its performance. Our system implementation has shown that excessive callbacks have a significant performance impact due to the single threaded nature of javascript. It would also flush out any unforeseen issues with the spec.
Intel/Tizen has implemented a similar capability and we have a good understanding I believe on this one but your comment is fair.  Part of this is the interface but part of this is implementation detail.  Maybe Kevron can share our learnings on this particular topic a some point to help the group.

  *   We should keep in mind being able to extend the Vehicle object to connect to a remote vehicle. There are manufacturers that are interested in a BYOD approach where there is no display but the driver's phone would be docked and used as the display.
What is one or two use cases and what are the security implications brought on by this?  To me this has nothing to do with a vehicle sensor spec.  This sounds more like a platform implementation detail.  I'm not sure OEMs really want a web app from a phone being able to make a method call on an interface that is implemented in the IVI stack over BT or WiFi.  This sounds like a security nightmare, but maybe I'm misinformed or don't understand what you're asking.

  *   For the flat vs categorized issue in the documentation: There are far too many sensors to put everything in a flat structure. As a developer it would be very difficult to memorize all of the sensors, it is far easier to memorize a dozen or so categories and find the sensor you would like within those categories. We recommend keeping those categories.


  *   Has anyone explored how this will work with Cordova? Cordova is the leading cross-platform development framework which most people would use for writing HTML5 applications, so we should keep it in mind.
     *   Would this work as a Cordova plugin?
     *   If not, would this need to be baked into the web platform of the vehicle? How would this impact remote device (BYOD) support?
  *   We would like to see real world sample applications to see how usable all of this is, especially the Cordova issues.
     *   This would also test the feasibility of the spec interfaces
We've (this group) have had discussions about Cordova before, have you read the mail archives?  I think we've been down that road before and nothing in this spec or any of the other W3C specs, take any of the mobile specifics spec for example, none of them do anything to support Cordova.  OEMs aren't interested in building a huge app ecosystem.  From a Linux perspective, we at Intel have built our own WRT and that's where we support Cordova.  We don't' expect the specs from the W3C to address it or do anything special to accommodate it.  This is a platform implementation detail and I don't understand why QNX keeps bringing this up because it's only QNX that brings this up.  Please explain and educate me.
Thanks,
Tina