cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 20:23:07 GMT
The <feature> tags list only those plugins which are relevant to the
bridge. Also they map from exec bridge name to native code class name, and
have no information about which plugin they're from, or that plugin's id or
version.

As to multiple platforms, there are several reasons why I'm unlikely to add
this feature to platforms other than iOS or Android. First, I'm not set up
for development on any of the others. This is especially true of the ones
that can't be built on Mac, especially Windows (Phone). Second, I don't
know anything about developing on those platforms: I don't know the
libraries or tools (or C# for Windows et al). Third, what I'm ultimately
working on is getting the App Harness working nicely as a launcher and
testbed for mobile Chrome apps, which only support iOS and Android anyway.

I agree the platforms should strive for consistency, but any new features
have to start somewhere. This is a pretty straightforward implementation,
and with my work on Android and iOS as a reference, it should be quick to
add to other platforms.

Braden



On Wed, Nov 13, 2013 at 2:54 PM, Jesse <purplecabbage@gmail.com> wrote:

> Adding this to iOS and Android only is kind of mean.  What ends up
> happening is the high profile platforms (ie. the ones that get ALL the
> attention) get a new feature and the others 'appear' to be behind.  I think
> we should focus on remaining consistent to some degree, otherwise you end
> up just making more work for the other platform developers.
>
> This does not seem like it would be hard for you to implement on windows
> phone and blackberry as well, and having you spend a few minutes in those
> platforms would probably be a good thing anyway.
>
> I too am also not sure why the existing feature tag in config.xml is not
> enough.
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Nov 13, 2013 at 11:38 AM, Gorkem Ercan <gorkem.ercan@gmail.com
> >wrote:
>
> > Hey Braden,
> > Why is not the current <feature> tags sufficient for this?
> > --
> > Gorkem
> >
> >
> > On Wed, Nov 13, 2013 at 2:32 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Hey folks,
> > >
> > > We've been kicking around the idea of getting at which plugins/versions
> > are
> > > installed, at runtime. In order to make that happen, I've taken the
> first
> > > step of having plugman prepare insert a tag into config.xml for each
> > > plugin. It will look like this:
> > >
> > > <plugins>
> > >   <plugin id="org.apache.cordova.file" version="0.2.5" />
> > >   <plugin id="org.apache.cordova.file-transfer" version="0.3.4" />
> > > </plugins>
> > >
> > > NB that Plugman is injecting this automatically, and this tag should
> NOT
> > > appear in the plugin.xml's <config-file> tags.
> > >
> > > Now I'll be adding logic to the config.xml parser on Android and iOS,
> but
> > > other platform maintainers will have to step in for the other
> platforms.
> > >
> > > Tracking the progress here:
> > https://issues.apache.org/jira/browse/CB-5379
> > >
> > > (If you're wondering why we have motivation for this, it's to make the
> > > AppHarness more informative, and more robust, by warning the user when
> an
> > > app they've installed is looking for plugins the harness can't provide,
> > or
> > > where versions mismatch.)
> > >
> > > Braden
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message