Re: some general spec feedback for consideration

Thanks Tina.   See my comments in line below...

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes




On Apr 15, 2014, at 9:54 PM, Tina Jeffrey <tjeffrey@qnx.com<mailto:tjeffrey@qnx.com>> wrote:

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.

Most implementers are more amenable to reading versus setting.  That said, many of these data elements are only readable and many are settable.  Anything that is potentially settable like HVAC should be left to the implementer to decide if they wish for it to be only readable or both readable and settable.

  *
     *
  *   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.

Per our discussion at the face to face and on the list, what is available for history is dependent on the implementation, but the mechanism to get history should be consistent and durable.  No one has claimed that all data should be available for spec compliance or for history.   This spec can comment on implementation details like performance, but by no means should address all them.    I encourage members of the group to share their implementation experience to help make the durable operations as clean as possible in the context of my comments.

  *
     *
  *   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.

There is nothing about the spec that would prevent it from being implemented on a non-embedded/remote device.  The spec makes no distinction between embedded in vehicle versus on remote device.

  *
  *   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.

Categorization is fine, but relatively arbitrary and getting everyone to agree on the common set may be difficult.  For example what should odometer go in a category called Running Status, Vehicle Information or Maintenance?  Isn’t Parking a type of Running Status or a category?  If it is a category, why?  In actuality I would think the implementer would categorize as they see fit.

  *
  *   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?

This is a platform agnostic interface specification that does not exclude Cordova or other platform implementation.  The group has considered the relationship to Cordova.  Feel free to make specific comments as to why the spec does not align with Cordova or other platforms, but the spec should remain platform agnostic.  It is an interface spec.

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

I encourage everyone in the group to implement and share their implementations as appropriate.


  *
     *

Thanks,
Tina