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

Re: Cordova

From: Philipp Hoschka <ph@w3.org>
Date: Thu, 17 Apr 2014 18:05:19 +0200
Message-ID: <534FFBBF.4050406@w3.org>
To: Marc Lapierre <mlapierre@qnx.com>
CC: "Abramski, Adam M" <adam.m.abramski@intel.com>, Tina Jeffrey <tjeffrey@qnx.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>, Nik Schultz <nschultz@qnx.com>, "Vadim Draluk (vadim.draluk@gm.com)" <vadim.draluk@gm.com>, Brian Leroux <brianl@adobe.com>
On 4/16/2014 6:10 PM, Marc Lapierre 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,

I'm not sure it isn't the typical say of doing things in Cordova - I'm 
not a great expert, but at least, quickly checking the camera API, at 
least the camera seems to be added to the navigator object in Cordova  - 
quoting from

> |navigator.camera.getPicture  <http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#camera.getPicture>(  cameraSuccess  <http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#cameraSuccess>,  cameraError  <http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#cameraError>,  [  cameraOptions  <http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#cameraOptions>  ]  );|

So is compass

> |navigator.compass.getCurrentHeading  <http://cordova.apache.org/docs/en/3.3.0/cordova_compass_compass.md.html#compass.getCurrentHeading>(compassSuccess  <http://cordova.apache.org/docs/en/3.3.0/cordova_compass_compass.md.html#compassSuccess>,  compassError  <http://cordova.apache.org/docs/en/3.3.0/cordova_compass_compass.md.html#compassError>,  compassOptions  <http://cordova.apache.org/docs/en/3.3.0/cordova_compass_compass.md.html#compassOptions>);|

(won't go through all of them)

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

I'm not aware of Cordova being used for APIs to remote devices (but 
again, I'm far from an expert) - however, more generally, I've seen JS 
app architectures (at least on paper) where a "local api" would be 
proxied and any calls then redirected to the remote device - this would 
be transparent to the caller - I'd assume one could do the same for a 
vehicle API running on a phone
Received on Thursday, 17 April 2014 16:05:51 UTC

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