cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gorkem Ercan <gorkem.er...@gmail.com>
Subject Re: Engines and plugins
Date Mon, 13 Jan 2014 23:14:50 GMT
On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
> FYI to others - the docs for this is found here (seems to have some
> incorrectly formatted markdown too :( ) :
> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
> 
> My understanding was that:
> <engine name="cordova-android" version=">=1.8.0" />
> is the same as:
> <engine name="cordova-android" version=">=1.8.0" platform="android" />
> not:
> <engine name="cordova" version=">=1.8.0" platform="android" />

What is actually different here? I know the implementation assumes all
platforms when it sees cordova but it does not have to, it could just
look take platform attribute into account. I am just
trying to understand the reasons for the cordova-${platform} engine
names.

> 
> 
> I think this is definitely open for discussion. As you say - usage of
> the tags are very limited right now.
> 
> Other concerns with it I have:
> - scriptSrc allows plugins to run code on the host machine upon
> install... Seems like a security concern.
> I *think* the answer to your question is that we want to be able to specify:
> <engine name="cordova-android" version=">=1.8.0" />
> <engine name="cordova-ios" version=">=1.9.0" />
> 
> And don't want cordova-ios checked when you don't have the android
> platform. And the syntax is more concise than:

I think this is a bit strict and makes life harder if iOS is not really
targeted by the application. Perhaps missing one of those engines should
be a warning and missing all of them a fail.

> <engine name="cordova-android" version=">=1.8.0" platform="android" />
> 
> 
> On Mon, Jan 13, 2014 at 2:33 PM, Gorkem Ercan <gorkem.ercan@gmail.com> wrote:
> > JBoss Tools have recently added the capability to switch between
> > Cordova engines. See [1] for details. While implementing checks for
> > plug-in compatibility I found the engine definitions on the plug-in specification
to
> > be more complex than needed to be.
> >
> > I think there are too many "default engines" defined.
> > for instance
> >   <engine name="cordova-android" version=">=1.8.0" />
> > is essentially the same as
> >   <engine name="cordova" version=">=1.8.0" platform="android" />
> >
> > Could someone remind the reason for having platform specific default engine names?
If
> > they exist for a historic reason can we remove it from the documentation
> > and guide people to use the platform attribute? I can provide a doc patch for this
purpose.
> > I think this is making the implementation on plugman more complex also.
> >
> > And specifying custom Apache Cordova-based frameworks is a different
> > beast altogether. It actually gives the responsibility to integrate a
> > custom engine with plugman to the plug-ins with the scriptSrc attribute.
> > I do not think this will scale considering that the engine and plug-in
> > ideally have a different life cycle. I think plugman should actually
> > provide a way for custom engines to provide this information.
> >
> > I guess there is some merit to engines such as "apple-xcode" but I have
> > yet not been able to find a plug-in that uses those. I must also admit
> > the use of engine definitions is also very limited.
> >
> > [1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html

Mime
View raw message