cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Coleman <don.cole...@gmail.com>
Subject Re: <plugins> tag, and accessing the plugin list
Date Thu, 14 Nov 2013 17:50:57 GMT
JavaScript only plugin implementations are valid on BlackBerry 10. Some
things that require native code on Android can be implemented in client
side JavaScript on BlackBerry using com.blackberry.invoke.


On Thu, Nov 14, 2013 at 12:26 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Thu, Nov 14, 2013 at 9:12 AM, Brian LeRoux <b@brian.io> wrote:
> > First thing: might as well give up on referencing config.xml as a
> standard.
> > That's a historical footnote of little relevance anymore!
> >
> > It feels leaky to define the mapping in <feature>. Would seem to me that
> > <feature> is a userland thing from a user perspective I want to know
> about
> > the ID and VERSION and the guts of what happens under the hood is none of
> > business. No?
> >
>
> This is actually where the mapping happens right now, and I really
> don't want to change this, since changing mapping would break
> EVERYTHING.  That being said, I don't know why we can't have feature
> tags with no *-package params.  That being said, I'm not sure what the
> point would even be, since JS-only plugins aren't really plugins at
> all and are just Javascript libraries.  Are there current examples of
> this in Cordova currently?
>
> >
> > On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
> >
> >> 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