cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron Abdullah <s...@adobe.com>
Subject Re: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 22:39:44 GMT
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
View raw message