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: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 21:39:41 GMT
If a plugin does not inject a feature tag for some reason it is the same
deal as before. Plugman injects one with the id and version as params.
If a plugin has multiple feature tags since they will have the same plugin
id and version you will still be able to introspect the plugin id and
version.

And apparently adobe sf just had a coffee break...
--
Gorkem


On Wed, Nov 13, 2013 at 4:27 PM, Braden Shepherdson <braden@chromium.org>wrote:

> I'm open to changing the names to something else, since I realize there
> used to be a <plugins> tag and <plugin> tags inside, before we used
> <feature>.
>
> Adding these as parameters on the <feature> tags is not enough, because the
> <feature> tags correspond to "names the bridge knows about", which is not
> quite "plugins". JS-only plugins don't appear here, and a single plugin can
> have multiple bridge names pointing at different classes.
>
> Braden
>
>
> On Wed, Nov 13, 2013 at 4:25 PM, Gorkem Ercan <gorkem.ercan@gmail.com
> >wrote:
>
> > It is unfortunate that the name attribute on the feature tag is not the
> > plugin id but a name. The uniqueness of the name is not guaranteed by
> > plugman so I can imagine this causing problems in the future.
> >
> > I can see the need for the tag but I am not sure id <plugin> tag is the
> > correct approach. There are plugins out there that are still using that
> tag
> > for instance [1] is from barcode scanner plugin from the registry. As an
> > alternate, <feature> tag can be used and id and version info can be
> > injected as additional <param> tags by plugman.
> >
> >
> > [1]   <config-file target="res/xml/plugins.xml" parent="/plugins">
> >             <plugin name="BarcodeScanner"
> > value="com.phonegap.plugins.barcodescanner.BarcodeScanner"/>
> >         </config-file>
> > --
> > Gorkem
> >
> >
> >
> > On Wed, Nov 13, 2013 at 3:23 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > 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