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

Re: some general spec feedback for consideration

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Tue, 15 Apr 2014 23:36:44 -0700
Message-ID: <CAFW5wYZo8eraa77ceEwpn=-hLvTGSwic=HgSJYjBw0=6+1iTSQ@mail.gmail.com>
To: Tina Jeffrey <tjeffrey@qnx.com>
Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>, Marc Lapierre <mlapierre@qnx.com>, Nik Schultz <nschultz@qnx.com>, "Vadim Draluk (vadim.draluk@gm.com)" <vadim.draluk@gm.com>
Thanks, Tina for the feedback.  Here's some responses inline:

On Tue, Apr 15, 2014 at 9:54 PM, Tina Jeffrey <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).

I've done an initial audit of the types and have a change ready to
push.  It should address some of the readonly issues.

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

Sensors that can be logically or functionally grouped are.  For
example, it makes sense to lump all the tire attributes into one
object: pressure, temperature, etc.  But sensors like vehicle speed
are kinda really a stand alone sensor.

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

I plan on starting an implementation in crosswalk very soon in
parallel with the finalization of the specs.  I'll keep the group
updated on how it's going.

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

Agreed.  I don't know if we need to add anything to the spec to
elaborate this, but I agree it is a valid use-case.  Perhaps
mentioning that the data may source remotely in the abstract?

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

I don't see why not.  The issues is going to be how the implementation
gets the data since there is no cross-platform way of getting the
data.  The implementation could target something like AMB[1] and pray
the OEM is using AMB in their system.  It's also possible to do remote
stuff with AMB for BYOD use-cases.

> 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

Agreed.  Hopefully we can get a few implementations going to really
hammer out any issues.  Implementing and then having apps actually use
the API is a huge step towards really nailing the API down IMHO.


[1] - https://github.com/otcshare/automotive-message-broker

> Thanks,
> Tina
Received on Wednesday, 16 April 2014 06:37:13 UTC

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