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

Great!  Definitely pipe up if you see cases where it won’t meet your needs.

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




On Apr 17, 2014, at 9:13 AM, Marc Lapierre <mlapierre@qnx.com<mailto:mlapierre@qnx.com>> wrote:

Hi Paul,

We're not saying it wouldn't work. We are just saying let's keep the use case in mind to ensure we don't go down a path where it wouldn't work.

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>
<714BCD18-EDAE-4E9A-A3BC-5E1992EAA888[19].png>
QNX Software Systems Limited
A subsidiary of BlackBerry

From: Paul Boyes <pb@opencar.com<mailto:pb@opencar.com>>
Date: Thursday, 17 April, 2014 11:39 AM
To: Marc Lapierre <mlapierre@qnx.com<mailto:mlapierre@qnx.com>>
Cc: Philipp Hoschka <ph@w3.org<mailto:ph@w3.org>>, "Abramski, Adam M" <adam.m.abramski@intel.com<mailto:adam.m.abramski@intel.com>>, 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>>
Subject: Re: Cordova (was: Re: some general spec feedback for consideration

Marc,

Would you please elaborate on use cases as to why the API will not work with remote devices?  Also other than the getting Vehicle object from Navigator would you please give very explicitly examples as to how is this spec limiting a Cordova implementation?

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




On Apr 16, 2014, at 9:10 AM, Marc Lapierre <mlapierre@qnx.com<mailto:mlapierre@qnx.com>> wrote:

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>
<714BCD18-EDAE-4E9A-A3BC-5E1992EAA888[16].png>
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.