cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 22:36:32 GMT
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.

It shouldn't be hard to just get the XML parsers on each of these
platforms to ignore param tags that it doesn't support or that don't
actually do anything.

We also dropped support for the plugin tag before we moved to 3.x, I
think we should stick to our decisions, and not go backward.  There's
no reason this can't be done with the feature tag.

> 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
View raw message