W3C home > Mailing lists > Public > public-autowebplatform@w3.org > April 2014

some general spec feedback for consideration

From: Tina Jeffrey <tjeffrey@qnx.com>
Date: Wed, 16 Apr 2014 04:54:27 +0000
To: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
CC: Marc Lapierre <mlapierre@qnx.com>, Nik Schultz <nschultz@qnx.com>, "Vadim Draluk (vadim.draluk@gm.com)" <vadim.draluk@gm.com>
Message-ID: <2E87066E7539BF43A9FE8BA775B03A96242B317F@exmbx4.ott.qnx.com>
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
     *   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.
  *   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.
  *   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
Received on Wednesday, 16 April 2014 04:54:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:52 UTC