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.

Regards,
Kevron

[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