cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 22:19:44 GMT
here's a query: what are we using <feature> for?


On Wed, Nov 13, 2013 at 1:39 PM, Gorkem Ercan <gorkem.ercan@gmail.com>wrote:

> 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