Re: Cordova (was: Re: some general spec feedback for consideration

Fully agreed, Adam,

I don't think we disagree at all. We don't expect to fully open up this API for everyone to be able to access all the data – I think this should be up to the implementation / OEM to decide what is best for their product.
We simply feel that the spec should allow all of these possibility if the implementation wishes it – we don't want to build a spec that will end up limiting the implementation.

There may be some confusion as to what I meant by allowing remote devices to connect to the vehicle. What we are aware of is the desire for the OEMs to write software that will run on mobile devices to connect to the vehicle remotely – not random third party applications. They would not lose control of they rook and feel or the user experience. Of course, if that desire were there, we would not want it to be limited by the API either.

Regards,

Marc Lapierre
Team Lead – HMI, Engineering Services
QNX CAR Platform

T +1 613 591 0931 ext. 24889
F +1 613 591 3579
E mlapierre@qnx.com<mailto:mlapierre@qnx.com>
[cid:7152587B-3CFD-4E4F-81A3-FDBDE45BDAC8]
QNX Software Systems Limited
A subsidiary of BlackBerry

From: <Abramski>, Adam M <adam.m.abramski@intel.com<mailto:adam.m.abramski@intel.com>>
Date: Wednesday, 16 April, 2014 1:03 PM
To: Marc Lapierre <mlapierre@qnx.com<mailto:mlapierre@qnx.com>>, Philipp Hoschka <ph@w3.org<mailto:ph@w3.org>>
Cc: Tina Jeffrey <tjeffrey@qnx.com<mailto:tjeffrey@qnx.com>>, "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>, Nik Schultz <nschultz@qnx.com<mailto:nschultz@qnx.com>>, "Vadim Draluk (vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>)" <vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>>, Brian Leroux <brianl@adobe.com<mailto:brianl@adobe.com>>, "Abramski, Adam M" <adam.m.abramski@intel.com<mailto:adam.m.abramski@intel.com>>
Subject: RE: Cordova (was: Re: some general spec feedback for consideration

Thanks Marc appreciate the discussion.

I get the value of Cordova.  I’ve used it in the past when I was at RIM and we worked closely with PhoneGap (Brian and company pre-Adobe acquisition) when we were defining the web platform for BlackBerry that you now use in automotive.

I think it’s really up to the OEMs to decide whether allowing vehicle data from the IVI HU be available to a remotely connected device.  We all know that OEMs differentiate their product offerings based on the HMI and by giving vehicle data to a remotely connected device, that device becomes (in part at least) the HMI for the car experience.  Not sure the verdict is out on what will happen but between security and “losing control” of the HMI/user experience to a remotely connected device is not what I’m hearing the OEMs would like to see today.  Maybe or obviously you’re hearing something different.

This spec is assuming (and the group has discussed this) that we’re talking about web apps not apps that run within a browser so if an OEM wanted to create a full HMI experience in web technology they could.  Also we’re assuming that all the vehicle data from the car’s network would/could be exposed to the IVI HU platform, core apps (ie those created by the Tier 1s or OEMs) and possibly to 3rd party developer apps based on what the OEM would like to enable from a 3rd party perspective.  All of these would at least execute on and be supported from the IVI HU OS platform.  I’d think that an OEM would want to control the vehicle data available to a remote device and even be able to “lock it down” to only those apps they want enabled on that remote device.  I think you are speaking generally making this available to any and all web apps on a remote device.  I think this is where we disagree.

Again, I’d like to hear what the Tier 1’s and OEMs think about this discussion.

Sincerely,
Adam

From: Marc Lapierre [mailto:mlapierre@qnx.com]
Sent: Wednesday, April 16, 2014 9:10 AM
To: Philipp Hoschka; Abramski, Adam M
Cc: Tina Jeffrey; public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; Nik Schultz; Vadim Draluk (vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>); Brian Leroux
Subject: Re: Cordova (was: Re: some general spec feedback for consideration

Hi guys,

The idea behind Cordova for us is that is that it is essentially the main cross platform method of providing access to native services. With the proposed implementation, the vehicle object living inside the navigator object implies that the API will live on the web platform directly. There's nothing wrong with this per se, however this implies that the APIs will only be accessible on browser runtimes on the vehicle itself. If that is the goal, then this is certainly the more efficient way to implement this API.

One of our goals is to take this API and make it available to remote devices for connection to the vehicle. We don't expect those devices to have the vehicle APIs implemented into their web platform. Cordova allows us to add the APIs to any device, regardless of their web platform implementation

That said, there is nothing technically stopping us from making a Cordova plugin that will simply add the API onto the navigator object. It isn't really the typical way of doing thing, but if that's how things end up we won't be backed into a corner. I understand that the goal is to define a W3C spec and not a Cordova plugin, so I can see why Cordova is not a priority in the scope of things.

My main comment was more to keep in mind how a typical implementation will look in the grand scheme of things, and to start thinking about how a remote device implementation would work. In my mind, it would be likely to use Cordova – at least in the short term. The reality is that there is a demand for remote connectivity, which is one of the real strengths of a web environment. Perhaps this is something that will be looked at in the future, we are simply bringing it up as it is more of an immediate reality for us.


TL;DR: Cordova is mainly a concern for remote device connectivity and in our minds, the simplest/most widely accepted method of adding new standard APIs to the multiple platforms that will end up using these APIs. We aren't saying "drop everything and look at this", we are simply mentioning the road we were going down before the spec was drafted and the reasons for doing so, and seeing where the discussion lead.

Thanks,


Marc Lapierre
Team Lead – HMI, Engineering Services
QNX CAR Platform

T +1 613 591 0931 ext. 24889
F +1 613 591 3579
E mlapierre@qnx.com<mailto:mlapierre@qnx.com>
[cid:image001.png@01CF595A.6BA86340]
QNX Software Systems Limited
A subsidiary of BlackBerry

From: Philipp Hoschka <ph@w3.org<mailto:ph@w3.org>>
Date: Wednesday, 16 April, 2014 11:40 AM
To: "Abramski, Adam M" <adam.m.abramski@intel.com<mailto:adam.m.abramski@intel.com>>
Cc: Tina Jeffrey <tjeffrey@qnx.com<mailto:tjeffrey@qnx.com>>, "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>, Marc Lapierre <mlapierre@qnx.com<mailto:mlapierre@qnx.com>>, Nik Schultz <nschultz@qnx.com<mailto:nschultz@qnx.com>>, "Vadim Draluk (vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>)" <vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>>, Brian Leroux <brianl@adobe.com<mailto:brianl@adobe.com>>
Subject: Cordova (was: Re: some general spec feedback for consideration

[adding the "inventor" of PhoneGap (now Cordova) for potential comments]

On 4/16/2014 4:42 PM, Abramski, Adam M wrote:

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

My (very) layman's understanding is that as long as it's a Javascript API, you can write a Cordova plugin for it - looking at
http://cordova.apache.org/docs/en/edge/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide
I don't see any mention of restrictions on the API that a Cordova plugin would have to follow when exposing functionality to JS programmers - but it's probably worth for somebody else to check that (or Brian to confirm)


·

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

That's one way to put it.

The other way to put it is that at least initially the goal of PhoneGap (now Cordova) was to replace any of the phonegap JS APIs for which there is no W3C standard yet by the W3C standard version once that becomes available - see
http://www.creativebloq.com/ipad/brian-leroux-phonegap-8126169

Thus the name - "phonegap" - a tool to (temporarily) close the gap from Web to native

So by definition, no need to "support Cordova" in W3C specs


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
Agree that Cordova is one way to implement the API, and from what I understand, this should be possible

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.