cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 22:54:44 GMT
Name is what is used in Javascript so it would be pretty painful to
use and just like Gorkem said having multiple <feature>s for the same
plugin is a non issue if they enclose <param name="plugin_id"...> and
<param name="version"....>

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