cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: <plugins> tag, and accessing the plugin list
Date Thu, 14 Nov 2013 00:25:19 GMT
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