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 Thu, 14 Nov 2013 16:32:27 GMT
I'm going to try to summarize some points so we can get on the same page.

tl;dr: see the last two paragraphs for what I'm actually proposing.

First, background on why we have <feature> tags. They map a bridge name
(eg. "FileTransfer" on all platforms) used with cordova.exec() to the
native code module that implements the plugin (eg.
"org.apache.cordova.filetransfer.FileTransfer" on Android,
"CDVFileTransfer" on iOS, etc.). The native side of the bridge uses this
information to load and call the right plugin's implementation after a
cordova.exec() call.

Note that a plugin can define 0 or more <feature> tags. Plugins with no
native code won't have one. In principle, a plugin can have more than one,
though we can't think of any examples of that.

When I first looked at this problem of wanting to know, at runtime, what
plugins are installed, I originally considered using cordova_plugins.js to
learn the information. There are two problems here. One, the file doesn't
include information about plugin id and version. We could add it, but the
second problem is that cordova_plugins.js maps <js-module> names (used with
cordova.require()) to file names. Here again any one plugin can have 0 or
more <js-modules>; many have several.

I then considered using the <feature> tags. The same problems apply here:
they don't map 1-1, and don't have the data we need.

Others in the thread have proposed adding this data to the <feature> tags,
and adding <feature> tags automatically for plugins that don't already have
one (or alternatively, adding a new, autogenerated <feature> for every
plugin). The problem here is that the various native platforms are
expecting each <feature> to define a bridge name -> native code module
mapping, and these new ones won't do so. This is a potentially
bug-introducing change, because we'll have to make sure every platform can
handle these new tags which aren't like the old ones.

All of this led to my original proposal: add a new top-level tag,
<plugins>, whose children are exactly one <plugin id="..." version="..." />
for every plugin installed on this platform. We would then have two
separate lists in config.xml, but they are listing different things (bridge
mappings vs. plugins) for different purposes. Since this is an addition,
the platforms that don't support the new tag will just ignore it safely.

I realize that the top-level <plugins> tag is something we had previously,
before moving to the W3C <widget> spec's <feature> tags instead. I'm
perfectly willing to change the name, to perhaps <installed-plugins>, to
avoid any confusion with the old <plugins> tag. Any better suggestions for
the names?


Braden



On Wed, Nov 13, 2013 at 7:25 PM, Shazron <shazron@gmail.com> wrote:

> Didn't recommend anything. Just seeing how the impact is. Didn't think of
> the native bits (the native code that has some js that they call into)
>
>
> On Wed, Nov 13, 2013 at 3:43 PM, Jesse <purplecabbage@gmail.com> wrote:
>
> > Currently installing the plugin org.apache.cordova.device will add a
> > different feature tag for each platform/project's config.xml.
> > <!-- firefoxos -->
> > <feature name="Device">
> > <param name="firefoxos-package" value="Device" />
> > </feature>
> >
> > <!-- android -->
> > <feature name="Device" >
> > <param name="android-package" value="org.apache.cordova.device.Device"/>
> > </feature>
> >
> > <!-- ios -->
> > <feature name="Device">
> > <param name="ios-package" value="CDVDevice"/>
> > </feature>
> >
> > <!-- blackberry -->
> > <feature name="Device" value="Device"/>
> > <!-- wp7 and wp8 -->
> > <feature name="Device">
> > <param name="wp-package" value="Device"/>
> > </feature>
> >
> > Also, presumably, the following can be used on ALL without conflict:
> >
> > <feature name="Device" value="Device">
> > <param name="firefoxos-package" value="Device" />
> > <param name="android-package" value="org.apache.cordova.device.Device"/>
> > <param name="ios-package" value="CDVDevice"/>
> > <param name="wp-package" value="Device"/>
> > </feature>
> >
> > It would be nice if blackberry supported the feature/param@name
> > ='bb-package'
> > but I don't think this is imperative.
> >
> > We are missing a couple points from Braden:
> > a) js only plugins do not have config.xml entries
> > b) one plugin may add multiple features ( not sure if this has ever
> > happened in practice, it may be easier to just force the plugin developer
> > to make their class have a single point of contact in the features list,
> > and delegate in their own code. )
> >
> > Shaz's recommendations break everything everywhere from what I can tell.
> > This would require changes to all existing plugins, AND all platform
> > bridges native bits, and cordova-js. I don't think we want to be this
> > destructive.
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Nov 13, 2013 at 3:11 PM, Shazron <shazron@gmail.com> wrote:
> >
> > > Let's see the impact of using ID as name
> > >
> > > 1. plugin.xml feature tag, name attribute -> change the value to the
> > plugin
> > > id. Or just remove the attribute, plugman can inject the plugin id
> > > automatically(?) so it is less error-prone - not sure
> > > 2. plugin's js -> change all service names to ID in cordova.exec
> > >
> > > For user upgrades, they would remove the old plugin, then add the new
> > one -
> > > so it's relatively painless I think.
> > >
> > >
> > > On Wed, Nov 13, 2013 at 2:47 PM, Brian LeRoux <b@brian.io> wrote:
> > >
> > > > so would it be insane to deprecate the name thing and just go ID?
> > > >
> > > > (Warning: I am insane.)
> > > >
> > > >
> > > > On Wed, Nov 13, 2013 at 2:39 PM, Shazron Abdullah <shaz@adobe.com>
> > > wrote:
> > > >
> > > > > Brian: plugin mapping "service js name" -> "service native
> > name/class"
> > > > >
> > > > > On 11/13/13 2:36 PM, "Brian LeRoux" <b@brian.io> wrote:
> > > > >
> > > > > >what are we using <feature> for?
> > > > > >
> > > > > >
> > > > > >On Wed, Nov 13, 2013 at 2:27 PM, Braden Shepherdson
> > > > > ><braden@google.com>wrote:
> > > > > >
> > > > > >> My concern with (ab)using feature tags for this is that
now
> > > platforms
> > > > > >>that
> > > > > >> don't know about these parameters, and especially about
the
> dummy
> > > ones
> > > > > >>for
> > > > > >> js-only plugins, have a bug, rather than a missing feature.
> > > > > >> On Nov 13, 2013 4:40 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