You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Braden Shepherdson <br...@chromium.org> on 2013/11/13 20:32:48 UTC
tag, and accessing the plugin list
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
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
See above re: why not <feature> tags. They are not 1-1 at all.
Braden
On Wed, Nov 13, 2013 at 4:29 PM, Anis KADRI <an...@gmail.com> wrote:
> I am no W3C standard api expert but it seems like you could just use
> the existing feature tag instead of introducing a new one [1]:
>
> "A feature has zero or more parameters associated with it."
>
> Example:
>
> <feature name="Camera" value="org.apache.cordova.camera">
> <param name="{ios,android}-package"
> value="CDVCamera|org.apache.cordova.camera.CameraLauncher">
> <param name="plugin_id" value="org.apache.cordova.camera">
> <param name="version" value="0.2.3">
> </feature>
>
> My understanding is a feature tag matches a plugin (not a subset) so
> why the duplication?
>
> [1] http://www.w3.org/TR/widgets/#feature
>
> On Wed, Nov 13, 2013 at 12:23 PM, Braden Shepherdson
> <br...@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 <pu...@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
> >> > >
> >> >
> >>
>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
I am no W3C standard api expert but it seems like you could just use
the existing feature tag instead of introducing a new one [1]:
"A feature has zero or more parameters associated with it."
Example:
<feature name="Camera" value="org.apache.cordova.camera">
<param name="{ios,android}-package"
value="CDVCamera|org.apache.cordova.camera.CameraLauncher">
<param name="plugin_id" value="org.apache.cordova.camera">
<param name="version" value="0.2.3">
</feature>
My understanding is a feature tag matches a plugin (not a subset) so
why the duplication?
[1] http://www.w3.org/TR/widgets/#feature
On Wed, Nov 13, 2013 at 12:23 PM, Braden Shepherdson
<br...@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 <pu...@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
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
Braden, other than JS-only plugins (which could be added as <feature>s
and get ignored by native platforms) do you have an example of plugins
that use multiple <feature> tags ?
On Wed, Nov 13, 2013 at 1:32 PM, Anis KADRI <an...@gmail.com> wrote:
> no we just all responded at once.
>
> On Wed, Nov 13, 2013 at 1:31 PM, Braden Shepherdson <br...@chromium.org> wrote:
>> Did everyone at Adobe SF just come out of a meeting and see this at once?
>>
>> Braden
>>
>>
>> On Wed, Nov 13, 2013 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> So, specifically, you require ID and VERSION for runtime introspection?
>>>
>>> Why not just add that to <feature>?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 13, 2013 at 12: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 <pu...@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
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
no we just all responded at once.
On Wed, Nov 13, 2013 at 1:31 PM, Braden Shepherdson <br...@chromium.org> wrote:
> Did everyone at Adobe SF just come out of a meeting and see this at once?
>
> Braden
>
>
> On Wed, Nov 13, 2013 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> So, specifically, you require ID and VERSION for runtime introspection?
>>
>> Why not just add that to <feature>?
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 12: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 <pu...@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
>> > > > >
>> > > >
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Jesse <pu...@gmail.com>.
... a meeting about this thread even! ;)
@purplecabbage
risingj.com
On Wed, Nov 13, 2013 at 1:31 PM, Braden Shepherdson <br...@chromium.org>wrote:
> Did everyone at Adobe SF just come out of a meeting and see this at once?
>
> Braden
>
>
> On Wed, Nov 13, 2013 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > So, specifically, you require ID and VERSION for runtime introspection?
> >
> > Why not just add that to <feature>?
> >
> >
> >
> >
> >
> >
> > On Wed, Nov 13, 2013 at 12: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 <pu...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
Did everyone at Adobe SF just come out of a meeting and see this at once?
Braden
On Wed, Nov 13, 2013 at 4:29 PM, Brian LeRoux <b...@brian.io> wrote:
> So, specifically, you require ID and VERSION for runtime introspection?
>
> Why not just add that to <feature>?
>
>
>
>
>
>
> On Wed, Nov 13, 2013 at 12: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 <pu...@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
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
So, specifically, you require ID and VERSION for runtime introspection?
Why not just add that to <feature>?
On Wed, Nov 13, 2013 at 12:23 PM, Braden Shepherdson <br...@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 <pu...@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
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Joe Bowser <bo...@gmail.com>.
On Wed, Nov 13, 2013 at 2:27 PM, Braden Shepherdson <br...@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" <go...@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 <pu...@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
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
Please do, maybe break down in bullet form in the config thread.
On Thu, Nov 14, 2013 at 11:47 AM, Braden Shepherdson <br...@chromium.org>wrote:
> Brian, I think you're a bit confused about which information is in what
> files. I can break that down here if people would find it valuable.
>
> That timing works for me, Anis. I'll see you, and any other interested
> parties, there and then. If you're not Anis, add +Braden Shepherdson ahead
> of time and I'll make sure you get added into the Hangout.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 2:36 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > This is helpful. I think my impedance mismatch here is how we ended up
> with
> > plugin.xml information (bridge mappings) in a user config file while ID
> and
> > VERSION ended up in a generated file. I know we aren't interested in
> > changing stuff that already works but I like to fully understand where we
> > are at. In any case, throwing this in an already generated file makes
> > perfect sense for this particular case. For some reason I thought we were
> > proposing another new config file which, hopefully, does not become
> > necessary.
> >
> > In other words: +1
> >
> > (This said, I would like to keep rolling on the other config file
> > discussion to see if it is possible to consolidate that mess into
> something
> > more maintainable.)
> >
> >
> >
> > On Thu, Nov 14, 2013 at 10:44 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > I'm going to attempt to summarize in point form:
> > >
> > > Goal:
> > > - Make available the list of installed plugins and their versions to
> > > native side & JS side.
> > > - Needed by App Harness to know whether an app is compatible with its
> > > bundled set of plugins.
> > >
> > > Using cordova_plugins.js:
> > > - It doesn't have the information that we need
> > > - We could add the extra information, but not easily since the file
> > > exports an array instead of an object.
> > > - This file is not currently parsed by the native layer, so having the
> > > info here would be an extra IO on start-up.
> > >
> > > Using config.xml:
> > > - It doesn't have the information that we need
> > > - This is always loaded by native sides, so it's a nice fit.
> > >
> > > Using <feature>:
> > > - These are for defining Bridge channels
> > > - Plugins define 0 or more of these
> > > - Adding empty ones for plugins that don't define them causes
> exceptions
> > > in the native layer. We'd like this change to not break older versions
> of
> > > cordova.
> > >
> > > So, although it seems like <feature> would make sense, we've already
> used
> > > <feature> to mean something else (bridge channels).
> > >
> > > I think Braden's suggestion of adding a new tag is the simplest, both
> > > implementation-wise, as well as semantically (it has a single,
> > well-defined
> > > purpose). What I especially like about it, is that it separates which
> > tags
> > > are written by plugin devs (<feature>) from tags that are generated by
> > > plugman (<cordova-plugin>)
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > Ok, everybody be calm. We are adults and we are capable of working
> > > through
> > > > this in a dispassionate manner and has nothing to do with you, your
> > code,
> > > > or whatever. We all just want to find the best solution. Blankets
> > > > statements like 'more hacky code' does no good. Let's just stick to
> > > factual
> > > > stuff and stay away from subjective identification. Ok?
> > > >
> > > > "as to leaking into userland, these <feature> tags are relevant to
> > plugin
> > > > developers" ... so would this particular information belong to
> > > > plugin.xml????
> > > >
> > > > Also, Joe had a good question earlier. Despite all this problem
> > solving I
> > > > have no idea what the actual problem is we are trying to solve. We
> have
> > > > lots of solutions but what precisely do our users gain from runtime
> > > > introspection here?
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
> > > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > Brian, as to leaking into userland, these <feature> tags are
> relevant
> > > to
> > > > > plugin developers, since they have to define the mapping of exec
> > names
> > > to
> > > > > native files so we can load their plugins. None of this is visible
> to
> > > app
> > > > > developers or end users.
> > > > >
> > > > > We're not paying by the byte, or the top-level tag, in config.xml.
> NB
> > > > that
> > > > > this is the platform config.xml, the one that's a build artifact no
> > one
> > > > but
> > > > > the platform code is ever supposed to look at. Why are we sweating
> so
> > > > hard
> > > > > over adding some new information into the file, and trying to
> > shoehorn
> > > it
> > > > > into existing tags? The code to handle this is simpler in Plugman
> and
> > > on
> > > > > the platforms to have this be a separate tag, rather than mixing it
> > in
> > > > with
> > > > > <feature>.
> > > > >
> > > > > If we want to use <feature> tags for this, despite it requiring
> more,
> > > and
> > > > > more hacky, code all around, we're going to need a good reason. I
> > > haven't
> > > > > heard any reason for why using <feature> gains us anything.
> > > > >
> > > > > Carlos, as I noted in my remixed proposal above, I originally
> wanted
> > to
> > > > use
> > > > > cordova_plugins.js or a similar www/ file for this, but there are
> > > > problems
> > > > > with that. On the other hand, I would much rather add a new file
> that
> > > can
> > > > > be loaded as a js-module than do this using hacked-up <feature>
> tags.
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <
> don.coleman@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > 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 <bo...@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
> > > > > > > >> > > > > > ><br...@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
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> >
> > > > > > > >> > > > > > >>
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
Brian, I think you're a bit confused about which information is in what
files. I can break that down here if people would find it valuable.
That timing works for me, Anis. I'll see you, and any other interested
parties, there and then. If you're not Anis, add +Braden Shepherdson ahead
of time and I'll make sure you get added into the Hangout.
Braden
On Thu, Nov 14, 2013 at 2:36 PM, Brian LeRoux <b...@brian.io> wrote:
> This is helpful. I think my impedance mismatch here is how we ended up with
> plugin.xml information (bridge mappings) in a user config file while ID and
> VERSION ended up in a generated file. I know we aren't interested in
> changing stuff that already works but I like to fully understand where we
> are at. In any case, throwing this in an already generated file makes
> perfect sense for this particular case. For some reason I thought we were
> proposing another new config file which, hopefully, does not become
> necessary.
>
> In other words: +1
>
> (This said, I would like to keep rolling on the other config file
> discussion to see if it is possible to consolidate that mess into something
> more maintainable.)
>
>
>
> On Thu, Nov 14, 2013 at 10:44 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I'm going to attempt to summarize in point form:
> >
> > Goal:
> > - Make available the list of installed plugins and their versions to
> > native side & JS side.
> > - Needed by App Harness to know whether an app is compatible with its
> > bundled set of plugins.
> >
> > Using cordova_plugins.js:
> > - It doesn't have the information that we need
> > - We could add the extra information, but not easily since the file
> > exports an array instead of an object.
> > - This file is not currently parsed by the native layer, so having the
> > info here would be an extra IO on start-up.
> >
> > Using config.xml:
> > - It doesn't have the information that we need
> > - This is always loaded by native sides, so it's a nice fit.
> >
> > Using <feature>:
> > - These are for defining Bridge channels
> > - Plugins define 0 or more of these
> > - Adding empty ones for plugins that don't define them causes exceptions
> > in the native layer. We'd like this change to not break older versions of
> > cordova.
> >
> > So, although it seems like <feature> would make sense, we've already used
> > <feature> to mean something else (bridge channels).
> >
> > I think Braden's suggestion of adding a new tag is the simplest, both
> > implementation-wise, as well as semantically (it has a single,
> well-defined
> > purpose). What I especially like about it, is that it separates which
> tags
> > are written by plugin devs (<feature>) from tags that are generated by
> > plugman (<cordova-plugin>)
> >
> >
> >
> >
> >
> > On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Ok, everybody be calm. We are adults and we are capable of working
> > through
> > > this in a dispassionate manner and has nothing to do with you, your
> code,
> > > or whatever. We all just want to find the best solution. Blankets
> > > statements like 'more hacky code' does no good. Let's just stick to
> > factual
> > > stuff and stay away from subjective identification. Ok?
> > >
> > > "as to leaking into userland, these <feature> tags are relevant to
> plugin
> > > developers" ... so would this particular information belong to
> > > plugin.xml????
> > >
> > > Also, Joe had a good question earlier. Despite all this problem
> solving I
> > > have no idea what the actual problem is we are trying to solve. We have
> > > lots of solutions but what precisely do our users gain from runtime
> > > introspection here?
> > >
> > >
> > >
> > >
> > > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
> > braden@chromium.org
> > > >wrote:
> > >
> > > > Brian, as to leaking into userland, these <feature> tags are relevant
> > to
> > > > plugin developers, since they have to define the mapping of exec
> names
> > to
> > > > native files so we can load their plugins. None of this is visible to
> > app
> > > > developers or end users.
> > > >
> > > > We're not paying by the byte, or the top-level tag, in config.xml. NB
> > > that
> > > > this is the platform config.xml, the one that's a build artifact no
> one
> > > but
> > > > the platform code is ever supposed to look at. Why are we sweating so
> > > hard
> > > > over adding some new information into the file, and trying to
> shoehorn
> > it
> > > > into existing tags? The code to handle this is simpler in Plugman and
> > on
> > > > the platforms to have this be a separate tag, rather than mixing it
> in
> > > with
> > > > <feature>.
> > > >
> > > > If we want to use <feature> tags for this, despite it requiring more,
> > and
> > > > more hacky, code all around, we're going to need a good reason. I
> > haven't
> > > > heard any reason for why using <feature> gains us anything.
> > > >
> > > > Carlos, as I noted in my remixed proposal above, I originally wanted
> to
> > > use
> > > > cordova_plugins.js or a similar www/ file for this, but there are
> > > problems
> > > > with that. On the other hand, I would much rather add a new file that
> > can
> > > > be loaded as a js-module than do this using hacked-up <feature> tags.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <don.coleman@gmail.com
> >
> > > > wrote:
> > > >
> > > > > 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 <bo...@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 <sh...@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
> > > > > > >> > > > > > ><br...@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
> > > > > > >> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >> > > > > > >
> > > > > > >> > > > > > >> > > > > >
> > > > > > >> > > > > > >> > > > >
> > > > > > >> > > > > > >> > > >
> > > > > > >> > > > > > >> > >
> > > > > > >> > > > > > >> >
> > > > > > >> > > > > > >>
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
This is helpful. I think my impedance mismatch here is how we ended up with
plugin.xml information (bridge mappings) in a user config file while ID and
VERSION ended up in a generated file. I know we aren't interested in
changing stuff that already works but I like to fully understand where we
are at. In any case, throwing this in an already generated file makes
perfect sense for this particular case. For some reason I thought we were
proposing another new config file which, hopefully, does not become
necessary.
In other words: +1
(This said, I would like to keep rolling on the other config file
discussion to see if it is possible to consolidate that mess into something
more maintainable.)
On Thu, Nov 14, 2013 at 10:44 AM, Andrew Grieve <ag...@chromium.org>wrote:
> I'm going to attempt to summarize in point form:
>
> Goal:
> - Make available the list of installed plugins and their versions to
> native side & JS side.
> - Needed by App Harness to know whether an app is compatible with its
> bundled set of plugins.
>
> Using cordova_plugins.js:
> - It doesn't have the information that we need
> - We could add the extra information, but not easily since the file
> exports an array instead of an object.
> - This file is not currently parsed by the native layer, so having the
> info here would be an extra IO on start-up.
>
> Using config.xml:
> - It doesn't have the information that we need
> - This is always loaded by native sides, so it's a nice fit.
>
> Using <feature>:
> - These are for defining Bridge channels
> - Plugins define 0 or more of these
> - Adding empty ones for plugins that don't define them causes exceptions
> in the native layer. We'd like this change to not break older versions of
> cordova.
>
> So, although it seems like <feature> would make sense, we've already used
> <feature> to mean something else (bridge channels).
>
> I think Braden's suggestion of adding a new tag is the simplest, both
> implementation-wise, as well as semantically (it has a single, well-defined
> purpose). What I especially like about it, is that it separates which tags
> are written by plugin devs (<feature>) from tags that are generated by
> plugman (<cordova-plugin>)
>
>
>
>
>
> On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Ok, everybody be calm. We are adults and we are capable of working
> through
> > this in a dispassionate manner and has nothing to do with you, your code,
> > or whatever. We all just want to find the best solution. Blankets
> > statements like 'more hacky code' does no good. Let's just stick to
> factual
> > stuff and stay away from subjective identification. Ok?
> >
> > "as to leaking into userland, these <feature> tags are relevant to plugin
> > developers" ... so would this particular information belong to
> > plugin.xml????
> >
> > Also, Joe had a good question earlier. Despite all this problem solving I
> > have no idea what the actual problem is we are trying to solve. We have
> > lots of solutions but what precisely do our users gain from runtime
> > introspection here?
> >
> >
> >
> >
> > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> >
> > > Brian, as to leaking into userland, these <feature> tags are relevant
> to
> > > plugin developers, since they have to define the mapping of exec names
> to
> > > native files so we can load their plugins. None of this is visible to
> app
> > > developers or end users.
> > >
> > > We're not paying by the byte, or the top-level tag, in config.xml. NB
> > that
> > > this is the platform config.xml, the one that's a build artifact no one
> > but
> > > the platform code is ever supposed to look at. Why are we sweating so
> > hard
> > > over adding some new information into the file, and trying to shoehorn
> it
> > > into existing tags? The code to handle this is simpler in Plugman and
> on
> > > the platforms to have this be a separate tag, rather than mixing it in
> > with
> > > <feature>.
> > >
> > > If we want to use <feature> tags for this, despite it requiring more,
> and
> > > more hacky, code all around, we're going to need a good reason. I
> haven't
> > > heard any reason for why using <feature> gains us anything.
> > >
> > > Carlos, as I noted in my remixed proposal above, I originally wanted to
> > use
> > > cordova_plugins.js or a similar www/ file for this, but there are
> > problems
> > > with that. On the other hand, I would much rather add a new file that
> can
> > > be loaded as a js-module than do this using hacked-up <feature> tags.
> > >
> > > Braden
> > >
> > >
> > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <do...@gmail.com>
> > > wrote:
> > >
> > > > 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 <bo...@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 <sh...@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
> > > > > >> > > > > > ><br...@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
> > > > > >> > > > > > >> > > > > > > >
> > > > > >> > > > > > >> > > > > > >
> > > > > >> > > > > > >> > > > > >
> > > > > >> > > > > > >> > > > >
> > > > > >> > > > > > >> > > >
> > > > > >> > > > > > >> > >
> > > > > >> > > > > > >> >
> > > > > >> > > > > > >>
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > I'm going to attempt to summarize in point form:
> >
> > Goal:
> > - Make available the list of installed plugins and their versions to
> native side & JS
> > side.
> > - Needed by App Harness to know whether an app is compatible with its
> > bundled set of plugins.
> >
> > Using cordova_plugins.js:
> > - It doesn't have the information that we need
> > - We could add the extra information, but not easily since the file
> exports an
> > array instead of an object.
> > - This file is not currently parsed by the native layer, so having the
> info here
> > would be an extra IO on start-up.
> >
>
> Great summary :)
>
> Is it difficult to rename ' cordova_plugins.js' to something more broad
> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
> object?
> Since it's generated code, first impression is there's no BC issue other
> than doing another prepare.
>
cordova_plugins.js is consumed by cordova.js, so if we changed it, we'd
need plugman to do:
IF cordovaJsVersion < 3.3 THEN use old format ELSE use new format
probably not too bad to do.
> Doesn't seem like there's a way to avoid the extra IO on the native side
> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
> xml, how will the JS side access it?
>
Idea here is that JS would make an exec() to get the list if the JS side
wanted it.
>
> Broader problem is there's no single cordova meta file that's shared
> between native & js. Considering that on some platforms, there's only
> JavaScript, putting the information in JSON seems like a good move.
>
>
Re: tag, and accessing the plugin list
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Nov 14, 2013 at 10:22 PM, Andrew Grieve <ag...@chromium.org>wrote:
> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > So...
> >
> > We just had a good chat about this topic with Braden and Gorkem and we
> > think that adding <param>s to the existing <feature> tag is better
> > than introducing a new one.
> >
> > Pros:
> > - No new tags, less confusion.
>
> Unless we're going to add a new tag to do what <feature> currently does,
> I'd argue having one tag that does two things is more confusing.
>
>
> >
>
> - A good path towards having a unique top-level config.xml since we
> > can now identify which plugins are installed from the feature tag.
> > Therefore, we can better handle uninstalls and user edits to the file.
> >
> This makes me think I just don't understand what the proposal now is. An
>
I think I'm in this boat too. I originally thought proposal meant changing
the *platform config* by modifying the finally generated <feature> tag to
add new params, but after re-reading, seems you propose making changes to
the *app config* on plugin install time?
> example would help I think.
> Some questions:
> - Does this mean we're going to change <feature> to not directly define
> bridge mappings?
> - Is the idea to have a new tag within <feature> that defines the bridge
> binding?
> - If not:
> - what are we doing with plugins that define multiple <feature> tags?
> - what are we doing if apps directly define <feature> tags directly in
> their config.xml (outside of plugins)? This is still common for plugins
> that haven't been updated to plugman. I think we do this for plugins
> bundled with the platforms (e.g. Android's App plugin)
>
>
>
>
> >
> > Cons:
> > - Harder to implement for us. "Should still take less time than
> > arguing on the topic" said Braden ;-)
> > - Previous Cordova platforms might or might not choke when they see
> > JS-only plugins listed as <feature>s but it's unlikely.
> >
> Android chokes:
>
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
>
>
> Not sure if this was considered, but instead of using a config file, we
> could generate a source file that gets compiled in. Would eliminate any
> performance concerns and stay out of files that users might be peering at.
>
-1 to generating a source file. Besides being brittle to do that for each
platform, the compelling use case here is to warn when installing app into
app harness. We are only downloading the final generated web assets when
loading apps into app harness, so having a native file specify its expected
list of plugins seems like a bad fit.
Also, the performance of doing I/O only if/when you want to read the list
of installed plugins, which at the moment is going to happen when
installing a new app in app harness, not on every apps' startup, is not at
all a performance problem.
I would not at all mind seeing a new prepare artifact with this info
instead of modifying config.xml (though config.xml seems like the easiest
way).
>
>
> >
> >
> > On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> > <br...@chromium.org> wrote:
> > > Following up on my big config-and-metadata summary in the other thread,
> > the
> > > file in question here is the platform config.xml (that is,
> > > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> > > Significantly, this file is written by Plugman and CLI, and read by the
> > > native platform. The user never reads or writes this file directly in
> the
> > > normal flow of things.
> > >
> > > Braden
> > >
> > >
> > > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> > >
> > >> There's a bit of a BC issue here because cordova.js needs to know what
> > >> file to inject a <script> tag for, so it can load the file and then
> load
> > >> its module. That's why I hesitated to modify the format of that file,
> > >> originally. (It currently sets module.exports to an array of
> <js-module>
> > >> info.) Like Andrew says, entirely possible to make the change, just
> that
> > >> some care is required.
> > >>
> > >> Braden
> > >>
> > >>
> > >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> > >> jbondc@gdesolutions.com> wrote:
> > >>
> > >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > >>> > I'm going to attempt to summarize in point form:
> > >>> >
> > >>> > Goal:
> > >>> > - Make available the list of installed plugins and their versions
> to
> > >>> native side & JS
> > >>> > side.
> > >>> > - Needed by App Harness to know whether an app is compatible with
> > its
> > >>> > bundled set of plugins.
> > >>> >
> > >>> > Using cordova_plugins.js:
> > >>> > - It doesn't have the information that we need
> > >>> > - We could add the extra information, but not easily since the
> file
> > >>> exports an
> > >>> > array instead of an object.
> > >>> > - This file is not currently parsed by the native layer, so having
> > the
> > >>> info here
> > >>> > would be an extra IO on start-up.
> > >>> >
> > >>>
> > >>> Great summary :)
> > >>>
> > >>> Is it difficult to rename ' cordova_plugins.js' to something more
> broad
> > >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using
> an
> > >>> object?
> > >>> Since it's generated code, first impression is there's no BC issue
> > other
> > >>> than doing another prepare.
> > >>>
> > >>> Doesn't seem like there's a way to avoid the extra IO on the native
> > side
> > >>> (e.g. cordova_meta.js). If the detailed list of installed plugins is
> in
> > >>> xml, how will the JS side access it?
> > >>>
> > >>> Broader problem is there's no single cordova meta file that's shared
> > >>> between native & js. Considering that on some platforms, there's only
> > >>> JavaScript, putting the information in JSON seems like a good move.
> > >>>
> > >>>
> > >>
> >
>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
Yup that is a sound plan. I think we should continue discussion on the
config file thing however. We have clearly accumulated some technical debt
here as it is difficult to reason (even describe) the config file dog pile.
Given the maturity of Cordova I feel paying off tech debt is crucially
important so we can keep adding new features without making everything
super brittle.
On Fri, Nov 15, 2013 at 10:48 AM, purplecabbage <pu...@gmail.com>wrote:
> +1 to the short term fix and the deep dive punt
>
> Sent from my iPhone
>
> > On Nov 15, 2013, at 10:19 AM, Michal Mocny <mm...@chromium.org> wrote:
> >
> > Hmm, sounds pretty un-intrusive. Ship it!
> >
> > We should probably schedule a whole hack-a-thon for figuring out the
> future
> > of config files. Maybe at our next face-to-face meetup, or just
> schedule a
> > hangout in the new year?
> >
> > -Michal
> >
> >
> >> On Fri, Nov 15, 2013 at 12:29 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >> On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <cs...@gmail.com>
> >> wrote:
> >>> +1
> >>>
> >>> Yep I agree this way users can get list of plugins installed from
> >>> javascript pretty easy on all platforms from a web resource (i.e.
> >>> cordova_plugins.js
> >>> )
> >>>
> >>>
> >>> On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <agrieve@chromium.org
> >>> wrote:
> >>>
> >>>> That sounds good to me.
> >>>>
> >>>>
> >>>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <
> >> braden@chromium.org
> >>>>> wrote:
> >>>>
> >>>>> Looking back over all of this discussion, we have a growing trend of
> >>>>> dissatisfaction with the current config file setup. We've talked in
> >> the
> >>>>> past about moving to JSON format, Andrew is suggesting above
> replacing
> >>>> 99%
> >>>>> of <config-file> uses with specialized tags to inject permissions and
> >>>>> <feature>s, my summary in the other thread was pretty disgustingly
> >>>>> complicated, etc.
> >>>>>
> >>>>> I propose three things:
> >>>>> 1. Punt all discussion of overhauling configuration files to the new
> >>>> year.
> >>>>> 2. Drop my proposals above, as well as the summary Anis posted of
> last
> >>>>> night's discussion.
> >>>>> 3. Solve the immediate use-case of AppHarness wanting to know what
> >>>> plugins
> >>>>> are installed by injecting that object into a new key attached to the
> >>>> array
> >>>>> of JS modules in cordova_plugins.js.
> >>>>>
> >>>>> This modifies a file that is already clearly a build artifact and not
> >>>>> touched by humans. It is fully backward compatible, since the array
> >> of JS
> >>>>> modules is unchanged when viewed as an array. And it gets me access
> >> the
> >>>>> information I needed in the short term to build the AppHarness
> >>>>> functionality.
> >>>>>
> >>>>> How does that sound?
> >>>>>
> >>>>> Braden
> >>>>>
> >>>>>
> >>>>> On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <
> agrieve@chromium.org
> >>>>>> wrote:
> >>>>>
> >>>>>> I think the thing that irks me about the proposal to fiddle with
> >>>>>> <feature>s, is that right now plugins put them in <config-file>
> >> tags.
> >>>>> With
> >>>>>> these tags:
> >>>>>>
> >>>>>> - You can specify any target that's an xml file
> >>>>>> - You can specify any xpath in the parent attribute
> >>>>>> - plugman will splice in your XML into the target file
> >> if-and-only-if
> >>>>> there
> >>>>>> wasn't already another plugin that spliced in the exact same chunk
> >> into
> >>>>> the
> >>>>>> exact same place.
> >>>>>>
> >>>>>> Now, we're proposing to make this <config-file> rule even more
> >> complex:
> >>>>>> - You can specify any target that's an xml file
> >>>>>> - You can specify any xpath in the parent attribute
> >>>>>> NEW:
> >>>>>> - If you specify target="config.xml" AND you specify parent xpath
> >> that
> >>>>>> evaluates to the same things as parent="/widget" Then:
> >>>>>> - For each top-level <feature> element in your payload:
> >>>>>> - Plugman will insert two new <params> into it with your plugin
> >>>> ID &
> >>>>>> version
> >>>>>> - plugman will splice in your XML into the target file
> >> if-and-only-if
> >>>>> there
> >>>>>> wasn't already another plugin that spliced in the exact same chunk
> >> into
> >>>>> the
> >>>>>> exact same place.
> >>>>>> NEW:
> >>>>>> - If your plugin does not have any <config-file> targets that match
> >> the
> >>>>>> above conditions:
> >>>>>> - Plugman will add one for you with a default payload of a
> >> <feature>
> >>>>> with
> >>>>>> params.
> >>>>>>
> >>>>>>
> >>>>>> I haven't run it past any real-world users, but it if it sounds
> >>>>> complicated
> >>>>>> to me, then I'd be surprised if it wasn't also confusing to others.
> >>>>>>
> >>>>>> Maybe a fallout of this discussion is that it's hurting us to be
> >> using
> >>>>>> <config-file> for common things. Seems like it would be simpler for
> >>>> both
> >>>>>> plugman and plugin devs to have <feature> outside of <config-file>.
> >> If
> >>>>> this
> >>>>>> were the case, I'd be much more open to the idea of altering them
> >> when
> >>>> we
> >>>>>> spliced them in.
> >>>>>>
> >>>>>> Going a step further, Michal suggested in another thread that we
> >> just
> >>>>>> include the plugin.xml files directly in apps. The more I think
> >> about
> >>>>> this,
> >>>>>> the more it makes sense to me. Why are we even splicing things into
> >>>>>> config.xml? Seems like we're doing work to lose information. If we
> >> just
> >>>>>> included the plugin.xml files directly, we could read out the
> >>>> <feature>,
> >>>>>> <access>, plugin iD & version, even <js-module>s. If we want to keep
> >>>> all
> >>>>>> the runtime xml in one file, how about splice in the entire
> >> plugin.xml
> >>>>> into
> >>>>>> config.xml?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <anis.kadri@gmail.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <
> >> agrieve@chromium.org
> >>>>>
> >>>>>>> wrote:
> >>>>>>>> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <
> >> anis.kadri@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> So...
> >>>>>>>>>
> >>>>>>>>> We just had a good chat about this topic with Braden and Gorkem
> >>>> and
> >>>>> we
> >>>>>>>>> think that adding <param>s to the existing <feature> tag is
> >> better
> >>>>>>>>> than introducing a new one.
> >>>>>>>>>
> >>>>>>>>> Pros:
> >>>>>>>>> - No new tags, less confusion.
> >>>>>>>>
> >>>>>>>> Unless we're going to add a new tag to do what <feature>
> >> currently
> >>>>>> does,
> >>>>>>>> I'd argue having one tag that does two things is more confusing.
> >>>>>>>
> >>>>>>> As you say it's arguable but I tend to base my arguments on
> >>>> real-world
> >>>>>>> users rather than Cordova core developers.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> - A good path towards having a unique top-level config.xml
> >> since we
> >>>>>>>>> can now identify which plugins are installed from the feature
> >> tag.
> >>>>>>>>> Therefore, we can better handle uninstalls and user edits to
> >> the
> >>>>> file.
> >>>>>>>> This makes me think I just don't understand what the proposal
> >> now
> >>>> is.
> >>>>>> An
> >>>>>>>> example would help I think.
> >>>>>>>> Some questions:
> >>>>>>>> - Does this mean we're going to change <feature> to not directly
> >>>>> define
> >>>>>>>> bridge mappings?
> >>>>>>>
> >>>>>>> No
> >>>>>>>
> >>>>>>>> - Is the idea to have a new tag within <feature> that defines
> >>>> the
> >>>>>>> bridge
> >>>>>>>> binding?
> >>>>>>>
> >>>>>>> No
> >>>>>>>
> >>>>>>>> - If not:
> >>>>>>>> - what are we doing with plugins that define multiple
> >> <feature>
> >>>>>> tags?
> >>>>>>>
> >>>>>>> We define two <param>s that hold the plugin ID an version. In
> >> older
> >>>>>>> versions of cordova <feature> was called <plugin> and the mapping
> >> was
> >>>>>>> one-to-one and it still seems to be the case. If for whatever
> >> reason
> >>>>>>> one needs to have 2+ <feature>s for one plugin, all <feature> tags
> >>>>>>> should define <param>s that indicate ID/version.
> >>>>>>>
> >>>>>>>> - what are we doing if apps directly define <feature> tags
> >>>>> directly
> >>>>>> in
> >>>>>>>> their config.xml (outside of plugins)? This is still common for
> >>>>> plugins
> >>>>>>>> that haven't been updated to plugman. I think we do this for
> >>>> plugins
> >>>>>>>> bundled with the platforms (e.g. Android's App plugin)
> >>>>>>>
> >>>>>>> I am not sure I understand the question but everything gets
> >> defined
> >>>> in
> >>>>>>> the top-level config.xml (plugins, js-only plugins and
> >>>>>>> platform-specific things like Android's App plugin).
> >>>>>> I just wanted to point out that people still copy & paste in
> >> <feature>
> >>>>> tags
> >>>>>> directly into their config.xml for plugins that haven't been
> >>>>> plugmanified.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cons:
> >>>>>>>>> - Harder to implement for us. "Should still take less time than
> >>>>>>>>> arguing on the topic" said Braden ;-)
> >>>>>>>>> - Previous Cordova platforms might or might not choke when they
> >>>> see
> >>>>>>>>> JS-only plugins listed as <feature>s but it's unlikely.
> >>>>>>>> Android chokes:
> >>
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
> >>>>>>>
> >>>>>>> Can you be specifc ? From what I read from PluginManager.java and
> >>>>>>> PluginEntry.java is that it gets added to a HashMap but the class
> >>>> only
> >>>>>>> gets instantiated if "onload" <param> is defined or if
> >> getPlugin() is
> >>>>>>> called when JS is called but exec not called for JS-only plugins
> >>>>>>> right?
> >>>>>> Sorry, should have just tried it out before speaking up. I thought
> >>>>> adding a
> >>>>>> null key would be a problem, but it seems as though hash maps do
> >> allow
> >>>>>> them.
> >>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Not sure if this was considered, but instead of using a config
> >>>> file,
> >>>>> we
> >>>>>>>> could generate a source file that gets compiled in. Would
> >> eliminate
> >>>>> any
> >>>>>>>> performance concerns and stay out of files that users might be
> >>>>> peering
> >>>>>>> at.
> >>>>>>>
> >>>>>>> Sure but this would only solve the app-harness problem we could
> >> also
> >>>>>>> solve at least two more problems:
> >>>>>>> - Have one canonical config.xml which is a path to making
> >> platforms
> >>>>>>> true build artifacts.
> >>>>>>> - Have the ability install all plugins all at once (ala npm
> >> install).
> >>>>>> Good points. generating a source file == bad idea.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> >>>>>>>>> <br...@chromium.org> wrote:
> >>>>>>>>>> Following up on my big config-and-metadata summary in the
> >> other
> >>>>>>> thread,
> >>>>>>>>> the
> >>>>>>>>>> file in question here is the platform config.xml (that is,
> >>>>>>>>>> $PROJECT/platforms/<platform>/.../config.xml, see my
> >> summary).
> >>>>>>>>>> Significantly, this file is written by Plugman and CLI, and
> >> read
> >>>>> by
> >>>>>>> the
> >>>>>>>>>> native platform. The user never reads or writes this file
> >>>> directly
> >>>>>> in
> >>>>>>> the
> >>>>>>>>>> normal flow of things.
> >>>>>>>>>>
> >>>>>>>>>> Braden
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> >>>>>>> braden@chromium.org
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> There's a bit of a BC issue here because cordova.js needs to
> >>>> know
> >>>>>>> what
> >>>>>>>>>>> file to inject a <script> tag for, so it can load the file
> >> and
> >>>>> then
> >>>>>>> load
> >>>>>>>>>>> its module. That's why I hesitated to modify the format of
> >> that
> >>>>>> file,
> >>>>>>>>>>> originally. (It currently sets module.exports to an array of
> >>>>>>> <js-module>
> >>>>>>>>>>> info.) Like Andrew says, entirely possible to make the
> >> change,
> >>>>> just
> >>>>>>> that
> >>>>>>>>>>> some care is required.
> >>>>>>>>>>>
> >>>>>>>>>>> Braden
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> >>>>>>>>>>> jbondc@gdesolutions.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> >>>>>>>>>>>>> I'm going to attempt to summarize in point form:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Goal:
> >>>>>>>>>>>>> - Make available the list of installed plugins and their
> >>>>>>> versions to
> >>>>>>>>>>>> native side & JS
> >>>>>>>>>>>>> side.
> >>>>>>>>>>>>> - Needed by App Harness to know whether an app is
> >>>> compatible
> >>>>>> with
> >>>>>>>>> its
> >>>>>>>>>>>>> bundled set of plugins.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Using cordova_plugins.js:
> >>>>>>>>>>>>> - It doesn't have the information that we need
> >>>>>>>>>>>>> - We could add the extra information, but not easily
> >> since
> >>>>> the
> >>>>>>> file
> >>>>>>>>>>>> exports an
> >>>>>>>>>>>>> array instead of an object.
> >>>>>>>>>>>>> - This file is not currently parsed by the native
> >> layer, so
> >>>>>>> having
> >>>>>>>>> the
> >>>>>>>>>>>> info here
> >>>>>>>>>>>>> would be an extra IO on start-up.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Great summary :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is it difficult to rename ' cordova_plugins.js' to
> >> something
> >>>>> more
> >>>>>>> broad
> >>>>>>>>>>>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js'
> >> and
> >>>>>>> using an
> >>>>>>>>>>>> object?
> >>>>>>>>>>>> Since it's generated code, first impression is there's no
> >> BC
> >>>>> issue
> >>>>>>>>> other
> >>>>>>>>>>>> than doing another prepare.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Doesn't seem like there's a way to avoid the extra IO on
> >> the
> >>>>>> native
> >>>>>>>>> side
> >>>>>>>>>>>> (e.g. cordova_meta.js). If the detailed list of installed
> >>>>> plugins
> >>>>>>> is in
> >>>>>>>>>>>> xml, how will the JS side access it?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Broader problem is there's no single cordova meta file
> >> that's
> >>>>>> shared
> >>>>>>>>>>>> between native & js. Considering that on some platforms,
> >>>> there's
> >>>>>>> only
> >>>>>>>>>>>> JavaScript, putting the information in JSON seems like a
> >> good
> >>>>>> move.
> >>>
> >>>
> >>>
> >>> --
> >>> Carlos Santana
> >>> <cs...@gmail.com>
> >>
>
Re: tag, and accessing the plugin list
Posted by purplecabbage <pu...@gmail.com>.
+1 to the short term fix and the deep dive punt
Sent from my iPhone
> On Nov 15, 2013, at 10:19 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> Hmm, sounds pretty un-intrusive. Ship it!
>
> We should probably schedule a whole hack-a-thon for figuring out the future
> of config files. Maybe at our next face-to-face meetup, or just schedule a
> hangout in the new year?
>
> -Michal
>
>
>> On Fri, Nov 15, 2013 at 12:29 PM, Anis KADRI <an...@gmail.com> wrote:
>>
>> +1
>>
>> On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <cs...@gmail.com>
>> wrote:
>>> +1
>>>
>>> Yep I agree this way users can get list of plugins installed from
>>> javascript pretty easy on all platforms from a web resource (i.e.
>>> cordova_plugins.js
>>> )
>>>
>>>
>>> On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <agrieve@chromium.org
>>> wrote:
>>>
>>>> That sounds good to me.
>>>>
>>>>
>>>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <
>> braden@chromium.org
>>>>> wrote:
>>>>
>>>>> Looking back over all of this discussion, we have a growing trend of
>>>>> dissatisfaction with the current config file setup. We've talked in
>> the
>>>>> past about moving to JSON format, Andrew is suggesting above replacing
>>>> 99%
>>>>> of <config-file> uses with specialized tags to inject permissions and
>>>>> <feature>s, my summary in the other thread was pretty disgustingly
>>>>> complicated, etc.
>>>>>
>>>>> I propose three things:
>>>>> 1. Punt all discussion of overhauling configuration files to the new
>>>> year.
>>>>> 2. Drop my proposals above, as well as the summary Anis posted of last
>>>>> night's discussion.
>>>>> 3. Solve the immediate use-case of AppHarness wanting to know what
>>>> plugins
>>>>> are installed by injecting that object into a new key attached to the
>>>> array
>>>>> of JS modules in cordova_plugins.js.
>>>>>
>>>>> This modifies a file that is already clearly a build artifact and not
>>>>> touched by humans. It is fully backward compatible, since the array
>> of JS
>>>>> modules is unchanged when viewed as an array. And it gets me access
>> the
>>>>> information I needed in the short term to build the AppHarness
>>>>> functionality.
>>>>>
>>>>> How does that sound?
>>>>>
>>>>> Braden
>>>>>
>>>>>
>>>>> On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agrieve@chromium.org
>>>>>> wrote:
>>>>>
>>>>>> I think the thing that irks me about the proposal to fiddle with
>>>>>> <feature>s, is that right now plugins put them in <config-file>
>> tags.
>>>>> With
>>>>>> these tags:
>>>>>>
>>>>>> - You can specify any target that's an xml file
>>>>>> - You can specify any xpath in the parent attribute
>>>>>> - plugman will splice in your XML into the target file
>> if-and-only-if
>>>>> there
>>>>>> wasn't already another plugin that spliced in the exact same chunk
>> into
>>>>> the
>>>>>> exact same place.
>>>>>>
>>>>>> Now, we're proposing to make this <config-file> rule even more
>> complex:
>>>>>> - You can specify any target that's an xml file
>>>>>> - You can specify any xpath in the parent attribute
>>>>>> NEW:
>>>>>> - If you specify target="config.xml" AND you specify parent xpath
>> that
>>>>>> evaluates to the same things as parent="/widget" Then:
>>>>>> - For each top-level <feature> element in your payload:
>>>>>> - Plugman will insert two new <params> into it with your plugin
>>>> ID &
>>>>>> version
>>>>>> - plugman will splice in your XML into the target file
>> if-and-only-if
>>>>> there
>>>>>> wasn't already another plugin that spliced in the exact same chunk
>> into
>>>>> the
>>>>>> exact same place.
>>>>>> NEW:
>>>>>> - If your plugin does not have any <config-file> targets that match
>> the
>>>>>> above conditions:
>>>>>> - Plugman will add one for you with a default payload of a
>> <feature>
>>>>> with
>>>>>> params.
>>>>>>
>>>>>>
>>>>>> I haven't run it past any real-world users, but it if it sounds
>>>>> complicated
>>>>>> to me, then I'd be surprised if it wasn't also confusing to others.
>>>>>>
>>>>>> Maybe a fallout of this discussion is that it's hurting us to be
>> using
>>>>>> <config-file> for common things. Seems like it would be simpler for
>>>> both
>>>>>> plugman and plugin devs to have <feature> outside of <config-file>.
>> If
>>>>> this
>>>>>> were the case, I'd be much more open to the idea of altering them
>> when
>>>> we
>>>>>> spliced them in.
>>>>>>
>>>>>> Going a step further, Michal suggested in another thread that we
>> just
>>>>>> include the plugin.xml files directly in apps. The more I think
>> about
>>>>> this,
>>>>>> the more it makes sense to me. Why are we even splicing things into
>>>>>> config.xml? Seems like we're doing work to lose information. If we
>> just
>>>>>> included the plugin.xml files directly, we could read out the
>>>> <feature>,
>>>>>> <access>, plugin iD & version, even <js-module>s. If we want to keep
>>>> all
>>>>>> the runtime xml in one file, how about splice in the entire
>> plugin.xml
>>>>> into
>>>>>> config.xml?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <
>> agrieve@chromium.org
>>>>>
>>>>>>> wrote:
>>>>>>>> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <
>> anis.kadri@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> So...
>>>>>>>>>
>>>>>>>>> We just had a good chat about this topic with Braden and Gorkem
>>>> and
>>>>> we
>>>>>>>>> think that adding <param>s to the existing <feature> tag is
>> better
>>>>>>>>> than introducing a new one.
>>>>>>>>>
>>>>>>>>> Pros:
>>>>>>>>> - No new tags, less confusion.
>>>>>>>>
>>>>>>>> Unless we're going to add a new tag to do what <feature>
>> currently
>>>>>> does,
>>>>>>>> I'd argue having one tag that does two things is more confusing.
>>>>>>>
>>>>>>> As you say it's arguable but I tend to base my arguments on
>>>> real-world
>>>>>>> users rather than Cordova core developers.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> - A good path towards having a unique top-level config.xml
>> since we
>>>>>>>>> can now identify which plugins are installed from the feature
>> tag.
>>>>>>>>> Therefore, we can better handle uninstalls and user edits to
>> the
>>>>> file.
>>>>>>>> This makes me think I just don't understand what the proposal
>> now
>>>> is.
>>>>>> An
>>>>>>>> example would help I think.
>>>>>>>> Some questions:
>>>>>>>> - Does this mean we're going to change <feature> to not directly
>>>>> define
>>>>>>>> bridge mappings?
>>>>>>>
>>>>>>> No
>>>>>>>
>>>>>>>> - Is the idea to have a new tag within <feature> that defines
>>>> the
>>>>>>> bridge
>>>>>>>> binding?
>>>>>>>
>>>>>>> No
>>>>>>>
>>>>>>>> - If not:
>>>>>>>> - what are we doing with plugins that define multiple
>> <feature>
>>>>>> tags?
>>>>>>>
>>>>>>> We define two <param>s that hold the plugin ID an version. In
>> older
>>>>>>> versions of cordova <feature> was called <plugin> and the mapping
>> was
>>>>>>> one-to-one and it still seems to be the case. If for whatever
>> reason
>>>>>>> one needs to have 2+ <feature>s for one plugin, all <feature> tags
>>>>>>> should define <param>s that indicate ID/version.
>>>>>>>
>>>>>>>> - what are we doing if apps directly define <feature> tags
>>>>> directly
>>>>>> in
>>>>>>>> their config.xml (outside of plugins)? This is still common for
>>>>> plugins
>>>>>>>> that haven't been updated to plugman. I think we do this for
>>>> plugins
>>>>>>>> bundled with the platforms (e.g. Android's App plugin)
>>>>>>>
>>>>>>> I am not sure I understand the question but everything gets
>> defined
>>>> in
>>>>>>> the top-level config.xml (plugins, js-only plugins and
>>>>>>> platform-specific things like Android's App plugin).
>>>>>> I just wanted to point out that people still copy & paste in
>> <feature>
>>>>> tags
>>>>>> directly into their config.xml for plugins that haven't been
>>>>> plugmanified.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cons:
>>>>>>>>> - Harder to implement for us. "Should still take less time than
>>>>>>>>> arguing on the topic" said Braden ;-)
>>>>>>>>> - Previous Cordova platforms might or might not choke when they
>>>> see
>>>>>>>>> JS-only plugins listed as <feature>s but it's unlikely.
>>>>>>>> Android chokes:
>> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
>>>>>>>
>>>>>>> Can you be specifc ? From what I read from PluginManager.java and
>>>>>>> PluginEntry.java is that it gets added to a HashMap but the class
>>>> only
>>>>>>> gets instantiated if "onload" <param> is defined or if
>> getPlugin() is
>>>>>>> called when JS is called but exec not called for JS-only plugins
>>>>>>> right?
>>>>>> Sorry, should have just tried it out before speaking up. I thought
>>>>> adding a
>>>>>> null key would be a problem, but it seems as though hash maps do
>> allow
>>>>>> them.
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure if this was considered, but instead of using a config
>>>> file,
>>>>> we
>>>>>>>> could generate a source file that gets compiled in. Would
>> eliminate
>>>>> any
>>>>>>>> performance concerns and stay out of files that users might be
>>>>> peering
>>>>>>> at.
>>>>>>>
>>>>>>> Sure but this would only solve the app-harness problem we could
>> also
>>>>>>> solve at least two more problems:
>>>>>>> - Have one canonical config.xml which is a path to making
>> platforms
>>>>>>> true build artifacts.
>>>>>>> - Have the ability install all plugins all at once (ala npm
>> install).
>>>>>> Good points. generating a source file == bad idea.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
>>>>>>>>> <br...@chromium.org> wrote:
>>>>>>>>>> Following up on my big config-and-metadata summary in the
>> other
>>>>>>> thread,
>>>>>>>>> the
>>>>>>>>>> file in question here is the platform config.xml (that is,
>>>>>>>>>> $PROJECT/platforms/<platform>/.../config.xml, see my
>> summary).
>>>>>>>>>> Significantly, this file is written by Plugman and CLI, and
>> read
>>>>> by
>>>>>>> the
>>>>>>>>>> native platform. The user never reads or writes this file
>>>> directly
>>>>>> in
>>>>>>> the
>>>>>>>>>> normal flow of things.
>>>>>>>>>>
>>>>>>>>>> Braden
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
>>>>>>> braden@chromium.org
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> There's a bit of a BC issue here because cordova.js needs to
>>>> know
>>>>>>> what
>>>>>>>>>>> file to inject a <script> tag for, so it can load the file
>> and
>>>>> then
>>>>>>> load
>>>>>>>>>>> its module. That's why I hesitated to modify the format of
>> that
>>>>>> file,
>>>>>>>>>>> originally. (It currently sets module.exports to an array of
>>>>>>> <js-module>
>>>>>>>>>>> info.) Like Andrew says, entirely possible to make the
>> change,
>>>>> just
>>>>>>> that
>>>>>>>>>>> some care is required.
>>>>>>>>>>>
>>>>>>>>>>> Braden
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
>>>>>>>>>>> jbondc@gdesolutions.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
>>>>>>>>>>>>> I'm going to attempt to summarize in point form:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Goal:
>>>>>>>>>>>>> - Make available the list of installed plugins and their
>>>>>>> versions to
>>>>>>>>>>>> native side & JS
>>>>>>>>>>>>> side.
>>>>>>>>>>>>> - Needed by App Harness to know whether an app is
>>>> compatible
>>>>>> with
>>>>>>>>> its
>>>>>>>>>>>>> bundled set of plugins.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using cordova_plugins.js:
>>>>>>>>>>>>> - It doesn't have the information that we need
>>>>>>>>>>>>> - We could add the extra information, but not easily
>> since
>>>>> the
>>>>>>> file
>>>>>>>>>>>> exports an
>>>>>>>>>>>>> array instead of an object.
>>>>>>>>>>>>> - This file is not currently parsed by the native
>> layer, so
>>>>>>> having
>>>>>>>>> the
>>>>>>>>>>>> info here
>>>>>>>>>>>>> would be an extra IO on start-up.
>>>>>>>>>>>>
>>>>>>>>>>>> Great summary :)
>>>>>>>>>>>>
>>>>>>>>>>>> Is it difficult to rename ' cordova_plugins.js' to
>> something
>>>>> more
>>>>>>> broad
>>>>>>>>>>>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js'
>> and
>>>>>>> using an
>>>>>>>>>>>> object?
>>>>>>>>>>>> Since it's generated code, first impression is there's no
>> BC
>>>>> issue
>>>>>>>>> other
>>>>>>>>>>>> than doing another prepare.
>>>>>>>>>>>>
>>>>>>>>>>>> Doesn't seem like there's a way to avoid the extra IO on
>> the
>>>>>> native
>>>>>>>>> side
>>>>>>>>>>>> (e.g. cordova_meta.js). If the detailed list of installed
>>>>> plugins
>>>>>>> is in
>>>>>>>>>>>> xml, how will the JS side access it?
>>>>>>>>>>>>
>>>>>>>>>>>> Broader problem is there's no single cordova meta file
>> that's
>>>>>> shared
>>>>>>>>>>>> between native & js. Considering that on some platforms,
>>>> there's
>>>>>>> only
>>>>>>>>>>>> JavaScript, putting the information in JSON seems like a
>> good
>>>>>> move.
>>>
>>>
>>>
>>> --
>>> Carlos Santana
>>> <cs...@gmail.com>
>>
Re: tag, and accessing the plugin list
Posted by Michal Mocny <mm...@chromium.org>.
Hmm, sounds pretty un-intrusive. Ship it!
We should probably schedule a whole hack-a-thon for figuring out the future
of config files. Maybe at our next face-to-face meetup, or just schedule a
hangout in the new year?
-Michal
On Fri, Nov 15, 2013 at 12:29 PM, Anis KADRI <an...@gmail.com> wrote:
> +1
>
> On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <cs...@gmail.com>
> wrote:
> > +1
> >
> > Yep I agree this way users can get list of plugins installed from
> > javascript pretty easy on all platforms from a web resource (i.e.
> > cordova_plugins.js
> > )
> >
> >
> > On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
> >
> >> That sounds good to me.
> >>
> >>
> >> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <
> braden@chromium.org
> >> >wrote:
> >>
> >> > Looking back over all of this discussion, we have a growing trend of
> >> > dissatisfaction with the current config file setup. We've talked in
> the
> >> > past about moving to JSON format, Andrew is suggesting above replacing
> >> 99%
> >> > of <config-file> uses with specialized tags to inject permissions and
> >> > <feature>s, my summary in the other thread was pretty disgustingly
> >> > complicated, etc.
> >> >
> >> > I propose three things:
> >> > 1. Punt all discussion of overhauling configuration files to the new
> >> year.
> >> > 2. Drop my proposals above, as well as the summary Anis posted of last
> >> > night's discussion.
> >> > 3. Solve the immediate use-case of AppHarness wanting to know what
> >> plugins
> >> > are installed by injecting that object into a new key attached to the
> >> array
> >> > of JS modules in cordova_plugins.js.
> >> >
> >> > This modifies a file that is already clearly a build artifact and not
> >> > touched by humans. It is fully backward compatible, since the array
> of JS
> >> > modules is unchanged when viewed as an array. And it gets me access
> the
> >> > information I needed in the short term to build the AppHarness
> >> > functionality.
> >> >
> >> > How does that sound?
> >> >
> >> > Braden
> >> >
> >> >
> >> > On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agrieve@chromium.org
> >> > >wrote:
> >> >
> >> > > I think the thing that irks me about the proposal to fiddle with
> >> > > <feature>s, is that right now plugins put them in <config-file>
> tags.
> >> > With
> >> > > these tags:
> >> > >
> >> > > - You can specify any target that's an xml file
> >> > > - You can specify any xpath in the parent attribute
> >> > > - plugman will splice in your XML into the target file
> if-and-only-if
> >> > there
> >> > > wasn't already another plugin that spliced in the exact same chunk
> into
> >> > the
> >> > > exact same place.
> >> > >
> >> > > Now, we're proposing to make this <config-file> rule even more
> complex:
> >> > > - You can specify any target that's an xml file
> >> > > - You can specify any xpath in the parent attribute
> >> > > NEW:
> >> > > - If you specify target="config.xml" AND you specify parent xpath
> that
> >> > > evaluates to the same things as parent="/widget" Then:
> >> > > - For each top-level <feature> element in your payload:
> >> > > - Plugman will insert two new <params> into it with your plugin
> >> ID &
> >> > > version
> >> > > - plugman will splice in your XML into the target file
> if-and-only-if
> >> > there
> >> > > wasn't already another plugin that spliced in the exact same chunk
> into
> >> > the
> >> > > exact same place.
> >> > > NEW:
> >> > > - If your plugin does not have any <config-file> targets that match
> the
> >> > > above conditions:
> >> > > - Plugman will add one for you with a default payload of a
> <feature>
> >> > with
> >> > > params.
> >> > >
> >> > >
> >> > > I haven't run it past any real-world users, but it if it sounds
> >> > complicated
> >> > > to me, then I'd be surprised if it wasn't also confusing to others.
> >> > >
> >> > > Maybe a fallout of this discussion is that it's hurting us to be
> using
> >> > > <config-file> for common things. Seems like it would be simpler for
> >> both
> >> > > plugman and plugin devs to have <feature> outside of <config-file>.
> If
> >> > this
> >> > > were the case, I'd be much more open to the idea of altering them
> when
> >> we
> >> > > spliced them in.
> >> > >
> >> > > Going a step further, Michal suggested in another thread that we
> just
> >> > > include the plugin.xml files directly in apps. The more I think
> about
> >> > this,
> >> > > the more it makes sense to me. Why are we even splicing things into
> >> > > config.xml? Seems like we're doing work to lose information. If we
> just
> >> > > included the plugin.xml files directly, we could read out the
> >> <feature>,
> >> > > <access>, plugin iD & version, even <js-module>s. If we want to keep
> >> all
> >> > > the runtime xml in one file, how about splice in the entire
> plugin.xml
> >> > into
> >> > > config.xml?
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <
> agrieve@chromium.org
> >> >
> >> > > > wrote:
> >> > > > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <
> anis.kadri@gmail.com>
> >> > > > wrote:
> >> > > > >
> >> > > > >> So...
> >> > > > >>
> >> > > > >> We just had a good chat about this topic with Braden and Gorkem
> >> and
> >> > we
> >> > > > >> think that adding <param>s to the existing <feature> tag is
> better
> >> > > > >> than introducing a new one.
> >> > > > >>
> >> > > > >> Pros:
> >> > > > >> - No new tags, less confusion.
> >> > > > >
> >> > > > > Unless we're going to add a new tag to do what <feature>
> currently
> >> > > does,
> >> > > > > I'd argue having one tag that does two things is more confusing.
> >> > > >
> >> > > > As you say it's arguable but I tend to base my arguments on
> >> real-world
> >> > > > users rather than Cordova core developers.
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > >>
> >> > > > >
> >> > > > > - A good path towards having a unique top-level config.xml
> since we
> >> > > > >> can now identify which plugins are installed from the feature
> tag.
> >> > > > >> Therefore, we can better handle uninstalls and user edits to
> the
> >> > file.
> >> > > > >>
> >> > > > > This makes me think I just don't understand what the proposal
> now
> >> is.
> >> > > An
> >> > > > > example would help I think.
> >> > > > > Some questions:
> >> > > > > - Does this mean we're going to change <feature> to not directly
> >> > define
> >> > > > > bridge mappings?
> >> > > >
> >> > > > No
> >> > > >
> >> > > > > - Is the idea to have a new tag within <feature> that defines
> >> the
> >> > > > bridge
> >> > > > > binding?
> >> > > >
> >> > > > No
> >> > > >
> >> > > > > - If not:
> >> > > > > - what are we doing with plugins that define multiple
> <feature>
> >> > > tags?
> >> > > >
> >> > > > We define two <param>s that hold the plugin ID an version. In
> older
> >> > > > versions of cordova <feature> was called <plugin> and the mapping
> was
> >> > > > one-to-one and it still seems to be the case. If for whatever
> reason
> >> > > > one needs to have 2+ <feature>s for one plugin, all <feature> tags
> >> > > > should define <param>s that indicate ID/version.
> >> > > >
> >> > > > > - what are we doing if apps directly define <feature> tags
> >> > directly
> >> > > in
> >> > > > > their config.xml (outside of plugins)? This is still common for
> >> > plugins
> >> > > > > that haven't been updated to plugman. I think we do this for
> >> plugins
> >> > > > > bundled with the platforms (e.g. Android's App plugin)
> >> > > >
> >> > > > I am not sure I understand the question but everything gets
> defined
> >> in
> >> > > > the top-level config.xml (plugins, js-only plugins and
> >> > > > platform-specific things like Android's App plugin).
> >> > > >
> >> > > I just wanted to point out that people still copy & paste in
> <feature>
> >> > tags
> >> > > directly into their config.xml for plugins that haven't been
> >> > plugmanified.
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >>
> >> > > > >> Cons:
> >> > > > >> - Harder to implement for us. "Should still take less time than
> >> > > > >> arguing on the topic" said Braden ;-)
> >> > > > >> - Previous Cordova platforms might or might not choke when they
> >> see
> >> > > > >> JS-only plugins listed as <feature>s but it's unlikely.
> >> > > > >>
> >> > > > > Android chokes:
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
> >> > > >
> >> > > > Can you be specifc ? From what I read from PluginManager.java and
> >> > > > PluginEntry.java is that it gets added to a HashMap but the class
> >> only
> >> > > > gets instantiated if "onload" <param> is defined or if
> getPlugin() is
> >> > > > called when JS is called but exec not called for JS-only plugins
> >> > > > right?
> >> > > >
> >> > > Sorry, should have just tried it out before speaking up. I thought
> >> > adding a
> >> > > null key would be a problem, but it seems as though hash maps do
> allow
> >> > > them.
> >> > >
> >> > >
> >> > > > >
> >> > > > >
> >> > > > > Not sure if this was considered, but instead of using a config
> >> file,
> >> > we
> >> > > > > could generate a source file that gets compiled in. Would
> eliminate
> >> > any
> >> > > > > performance concerns and stay out of files that users might be
> >> > peering
> >> > > > at.
> >> > > >
> >> > > > Sure but this would only solve the app-harness problem we could
> also
> >> > > > solve at least two more problems:
> >> > > > - Have one canonical config.xml which is a path to making
> platforms
> >> > > > true build artifacts.
> >> > > > - Have the ability install all plugins all at once (ala npm
> install).
> >> > > >
> >> > > Good points. generating a source file == bad idea.
> >> > >
> >> > >
> >> > >
> >> > > >
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > >>
> >> > > > >>
> >> > > > >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> >> > > > >> <br...@chromium.org> wrote:
> >> > > > >> > Following up on my big config-and-metadata summary in the
> other
> >> > > > thread,
> >> > > > >> the
> >> > > > >> > file in question here is the platform config.xml (that is,
> >> > > > >> > $PROJECT/platforms/<platform>/.../config.xml, see my
> summary).
> >> > > > >> > Significantly, this file is written by Plugman and CLI, and
> read
> >> > by
> >> > > > the
> >> > > > >> > native platform. The user never reads or writes this file
> >> directly
> >> > > in
> >> > > > the
> >> > > > >> > normal flow of things.
> >> > > > >> >
> >> > > > >> > Braden
> >> > > > >> >
> >> > > > >> >
> >> > > > >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> >> > > > braden@chromium.org
> >> > > > >> >wrote:
> >> > > > >> >
> >> > > > >> >> There's a bit of a BC issue here because cordova.js needs to
> >> know
> >> > > > what
> >> > > > >> >> file to inject a <script> tag for, so it can load the file
> and
> >> > then
> >> > > > load
> >> > > > >> >> its module. That's why I hesitated to modify the format of
> that
> >> > > file,
> >> > > > >> >> originally. (It currently sets module.exports to an array of
> >> > > > <js-module>
> >> > > > >> >> info.) Like Andrew says, entirely possible to make the
> change,
> >> > just
> >> > > > that
> >> > > > >> >> some care is required.
> >> > > > >> >>
> >> > > > >> >> Braden
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> >> > > > >> >> jbondc@gdesolutions.com> wrote:
> >> > > > >> >>
> >> > > > >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> >> > > > >> >>> > I'm going to attempt to summarize in point form:
> >> > > > >> >>> >
> >> > > > >> >>> > Goal:
> >> > > > >> >>> > - Make available the list of installed plugins and their
> >> > > > versions to
> >> > > > >> >>> native side & JS
> >> > > > >> >>> > side.
> >> > > > >> >>> > - Needed by App Harness to know whether an app is
> >> compatible
> >> > > with
> >> > > > >> its
> >> > > > >> >>> > bundled set of plugins.
> >> > > > >> >>> >
> >> > > > >> >>> > Using cordova_plugins.js:
> >> > > > >> >>> > - It doesn't have the information that we need
> >> > > > >> >>> > - We could add the extra information, but not easily
> since
> >> > the
> >> > > > file
> >> > > > >> >>> exports an
> >> > > > >> >>> > array instead of an object.
> >> > > > >> >>> > - This file is not currently parsed by the native
> layer, so
> >> > > > having
> >> > > > >> the
> >> > > > >> >>> info here
> >> > > > >> >>> > would be an extra IO on start-up.
> >> > > > >> >>> >
> >> > > > >> >>>
> >> > > > >> >>> Great summary :)
> >> > > > >> >>>
> >> > > > >> >>> Is it difficult to rename ' cordova_plugins.js' to
> something
> >> > more
> >> > > > broad
> >> > > > >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js'
> and
> >> > > > using an
> >> > > > >> >>> object?
> >> > > > >> >>> Since it's generated code, first impression is there's no
> BC
> >> > issue
> >> > > > >> other
> >> > > > >> >>> than doing another prepare.
> >> > > > >> >>>
> >> > > > >> >>> Doesn't seem like there's a way to avoid the extra IO on
> the
> >> > > native
> >> > > > >> side
> >> > > > >> >>> (e.g. cordova_meta.js). If the detailed list of installed
> >> > plugins
> >> > > > is in
> >> > > > >> >>> xml, how will the JS side access it?
> >> > > > >> >>>
> >> > > > >> >>> Broader problem is there's no single cordova meta file
> that's
> >> > > shared
> >> > > > >> >>> between native & js. Considering that on some platforms,
> >> there's
> >> > > > only
> >> > > > >> >>> JavaScript, putting the information in JSON seems like a
> good
> >> > > move.
> >> > > > >> >>>
> >> > > > >> >>>
> >> > > > >> >>
> >> > > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
+1
On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <cs...@gmail.com> wrote:
> +1
>
> Yep I agree this way users can get list of plugins installed from
> javascript pretty easy on all platforms from a web resource (i.e.
> cordova_plugins.js
> )
>
>
> On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> That sounds good to me.
>>
>>
>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <braden@chromium.org
>> >wrote:
>>
>> > Looking back over all of this discussion, we have a growing trend of
>> > dissatisfaction with the current config file setup. We've talked in the
>> > past about moving to JSON format, Andrew is suggesting above replacing
>> 99%
>> > of <config-file> uses with specialized tags to inject permissions and
>> > <feature>s, my summary in the other thread was pretty disgustingly
>> > complicated, etc.
>> >
>> > I propose three things:
>> > 1. Punt all discussion of overhauling configuration files to the new
>> year.
>> > 2. Drop my proposals above, as well as the summary Anis posted of last
>> > night's discussion.
>> > 3. Solve the immediate use-case of AppHarness wanting to know what
>> plugins
>> > are installed by injecting that object into a new key attached to the
>> array
>> > of JS modules in cordova_plugins.js.
>> >
>> > This modifies a file that is already clearly a build artifact and not
>> > touched by humans. It is fully backward compatible, since the array of JS
>> > modules is unchanged when viewed as an array. And it gets me access the
>> > information I needed in the short term to build the AppHarness
>> > functionality.
>> >
>> > How does that sound?
>> >
>> > Braden
>> >
>> >
>> > On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agrieve@chromium.org
>> > >wrote:
>> >
>> > > I think the thing that irks me about the proposal to fiddle with
>> > > <feature>s, is that right now plugins put them in <config-file> tags.
>> > With
>> > > these tags:
>> > >
>> > > - You can specify any target that's an xml file
>> > > - You can specify any xpath in the parent attribute
>> > > - plugman will splice in your XML into the target file if-and-only-if
>> > there
>> > > wasn't already another plugin that spliced in the exact same chunk into
>> > the
>> > > exact same place.
>> > >
>> > > Now, we're proposing to make this <config-file> rule even more complex:
>> > > - You can specify any target that's an xml file
>> > > - You can specify any xpath in the parent attribute
>> > > NEW:
>> > > - If you specify target="config.xml" AND you specify parent xpath that
>> > > evaluates to the same things as parent="/widget" Then:
>> > > - For each top-level <feature> element in your payload:
>> > > - Plugman will insert two new <params> into it with your plugin
>> ID &
>> > > version
>> > > - plugman will splice in your XML into the target file if-and-only-if
>> > there
>> > > wasn't already another plugin that spliced in the exact same chunk into
>> > the
>> > > exact same place.
>> > > NEW:
>> > > - If your plugin does not have any <config-file> targets that match the
>> > > above conditions:
>> > > - Plugman will add one for you with a default payload of a <feature>
>> > with
>> > > params.
>> > >
>> > >
>> > > I haven't run it past any real-world users, but it if it sounds
>> > complicated
>> > > to me, then I'd be surprised if it wasn't also confusing to others.
>> > >
>> > > Maybe a fallout of this discussion is that it's hurting us to be using
>> > > <config-file> for common things. Seems like it would be simpler for
>> both
>> > > plugman and plugin devs to have <feature> outside of <config-file>. If
>> > this
>> > > were the case, I'd be much more open to the idea of altering them when
>> we
>> > > spliced them in.
>> > >
>> > > Going a step further, Michal suggested in another thread that we just
>> > > include the plugin.xml files directly in apps. The more I think about
>> > this,
>> > > the more it makes sense to me. Why are we even splicing things into
>> > > config.xml? Seems like we're doing work to lose information. If we just
>> > > included the plugin.xml files directly, we could read out the
>> <feature>,
>> > > <access>, plugin iD & version, even <js-module>s. If we want to keep
>> all
>> > > the runtime xml in one file, how about splice in the entire plugin.xml
>> > into
>> > > config.xml?
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com>
>> > wrote:
>> > >
>> > > > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <agrieve@chromium.org
>> >
>> > > > wrote:
>> > > > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com>
>> > > > wrote:
>> > > > >
>> > > > >> So...
>> > > > >>
>> > > > >> We just had a good chat about this topic with Braden and Gorkem
>> and
>> > we
>> > > > >> think that adding <param>s to the existing <feature> tag is better
>> > > > >> than introducing a new one.
>> > > > >>
>> > > > >> Pros:
>> > > > >> - No new tags, less confusion.
>> > > > >
>> > > > > Unless we're going to add a new tag to do what <feature> currently
>> > > does,
>> > > > > I'd argue having one tag that does two things is more confusing.
>> > > >
>> > > > As you say it's arguable but I tend to base my arguments on
>> real-world
>> > > > users rather than Cordova core developers.
>> > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >
>> > > > > - A good path towards having a unique top-level config.xml since we
>> > > > >> can now identify which plugins are installed from the feature tag.
>> > > > >> Therefore, we can better handle uninstalls and user edits to the
>> > file.
>> > > > >>
>> > > > > This makes me think I just don't understand what the proposal now
>> is.
>> > > An
>> > > > > example would help I think.
>> > > > > Some questions:
>> > > > > - Does this mean we're going to change <feature> to not directly
>> > define
>> > > > > bridge mappings?
>> > > >
>> > > > No
>> > > >
>> > > > > - Is the idea to have a new tag within <feature> that defines
>> the
>> > > > bridge
>> > > > > binding?
>> > > >
>> > > > No
>> > > >
>> > > > > - If not:
>> > > > > - what are we doing with plugins that define multiple <feature>
>> > > tags?
>> > > >
>> > > > We define two <param>s that hold the plugin ID an version. In older
>> > > > versions of cordova <feature> was called <plugin> and the mapping was
>> > > > one-to-one and it still seems to be the case. If for whatever reason
>> > > > one needs to have 2+ <feature>s for one plugin, all <feature> tags
>> > > > should define <param>s that indicate ID/version.
>> > > >
>> > > > > - what are we doing if apps directly define <feature> tags
>> > directly
>> > > in
>> > > > > their config.xml (outside of plugins)? This is still common for
>> > plugins
>> > > > > that haven't been updated to plugman. I think we do this for
>> plugins
>> > > > > bundled with the platforms (e.g. Android's App plugin)
>> > > >
>> > > > I am not sure I understand the question but everything gets defined
>> in
>> > > > the top-level config.xml (plugins, js-only plugins and
>> > > > platform-specific things like Android's App plugin).
>> > > >
>> > > I just wanted to point out that people still copy & paste in <feature>
>> > tags
>> > > directly into their config.xml for plugins that haven't been
>> > plugmanified.
>> > >
>> > >
>> > >
>> > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >> Cons:
>> > > > >> - Harder to implement for us. "Should still take less time than
>> > > > >> arguing on the topic" said Braden ;-)
>> > > > >> - Previous Cordova platforms might or might not choke when they
>> see
>> > > > >> JS-only plugins listed as <feature>s but it's unlikely.
>> > > > >>
>> > > > > Android chokes:
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
>> > > >
>> > > > Can you be specifc ? From what I read from PluginManager.java and
>> > > > PluginEntry.java is that it gets added to a HashMap but the class
>> only
>> > > > gets instantiated if "onload" <param> is defined or if getPlugin() is
>> > > > called when JS is called but exec not called for JS-only plugins
>> > > > right?
>> > > >
>> > > Sorry, should have just tried it out before speaking up. I thought
>> > adding a
>> > > null key would be a problem, but it seems as though hash maps do allow
>> > > them.
>> > >
>> > >
>> > > > >
>> > > > >
>> > > > > Not sure if this was considered, but instead of using a config
>> file,
>> > we
>> > > > > could generate a source file that gets compiled in. Would eliminate
>> > any
>> > > > > performance concerns and stay out of files that users might be
>> > peering
>> > > > at.
>> > > >
>> > > > Sure but this would only solve the app-harness problem we could also
>> > > > solve at least two more problems:
>> > > > - Have one canonical config.xml which is a path to making platforms
>> > > > true build artifacts.
>> > > > - Have the ability install all plugins all at once (ala npm install).
>> > > >
>> > > Good points. generating a source file == bad idea.
>> > >
>> > >
>> > >
>> > > >
>> > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >>
>> > > > >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
>> > > > >> <br...@chromium.org> wrote:
>> > > > >> > Following up on my big config-and-metadata summary in the other
>> > > > thread,
>> > > > >> the
>> > > > >> > file in question here is the platform config.xml (that is,
>> > > > >> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
>> > > > >> > Significantly, this file is written by Plugman and CLI, and read
>> > by
>> > > > the
>> > > > >> > native platform. The user never reads or writes this file
>> directly
>> > > in
>> > > > the
>> > > > >> > normal flow of things.
>> > > > >> >
>> > > > >> > Braden
>> > > > >> >
>> > > > >> >
>> > > > >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
>> > > > braden@chromium.org
>> > > > >> >wrote:
>> > > > >> >
>> > > > >> >> There's a bit of a BC issue here because cordova.js needs to
>> know
>> > > > what
>> > > > >> >> file to inject a <script> tag for, so it can load the file and
>> > then
>> > > > load
>> > > > >> >> its module. That's why I hesitated to modify the format of that
>> > > file,
>> > > > >> >> originally. (It currently sets module.exports to an array of
>> > > > <js-module>
>> > > > >> >> info.) Like Andrew says, entirely possible to make the change,
>> > just
>> > > > that
>> > > > >> >> some care is required.
>> > > > >> >>
>> > > > >> >> Braden
>> > > > >> >>
>> > > > >> >>
>> > > > >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
>> > > > >> >> jbondc@gdesolutions.com> wrote:
>> > > > >> >>
>> > > > >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
>> > > > >> >>> > I'm going to attempt to summarize in point form:
>> > > > >> >>> >
>> > > > >> >>> > Goal:
>> > > > >> >>> > - Make available the list of installed plugins and their
>> > > > versions to
>> > > > >> >>> native side & JS
>> > > > >> >>> > side.
>> > > > >> >>> > - Needed by App Harness to know whether an app is
>> compatible
>> > > with
>> > > > >> its
>> > > > >> >>> > bundled set of plugins.
>> > > > >> >>> >
>> > > > >> >>> > Using cordova_plugins.js:
>> > > > >> >>> > - It doesn't have the information that we need
>> > > > >> >>> > - We could add the extra information, but not easily since
>> > the
>> > > > file
>> > > > >> >>> exports an
>> > > > >> >>> > array instead of an object.
>> > > > >> >>> > - This file is not currently parsed by the native layer, so
>> > > > having
>> > > > >> the
>> > > > >> >>> info here
>> > > > >> >>> > would be an extra IO on start-up.
>> > > > >> >>> >
>> > > > >> >>>
>> > > > >> >>> Great summary :)
>> > > > >> >>>
>> > > > >> >>> Is it difficult to rename ' cordova_plugins.js' to something
>> > more
>> > > > broad
>> > > > >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and
>> > > > using an
>> > > > >> >>> object?
>> > > > >> >>> Since it's generated code, first impression is there's no BC
>> > issue
>> > > > >> other
>> > > > >> >>> than doing another prepare.
>> > > > >> >>>
>> > > > >> >>> Doesn't seem like there's a way to avoid the extra IO on the
>> > > native
>> > > > >> side
>> > > > >> >>> (e.g. cordova_meta.js). If the detailed list of installed
>> > plugins
>> > > > is in
>> > > > >> >>> xml, how will the JS side access it?
>> > > > >> >>>
>> > > > >> >>> Broader problem is there's no single cordova meta file that's
>> > > shared
>> > > > >> >>> between native & js. Considering that on some platforms,
>> there's
>> > > > only
>> > > > >> >>> JavaScript, putting the information in JSON seems like a good
>> > > move.
>> > > > >> >>>
>> > > > >> >>>
>> > > > >> >>
>> > > > >>
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
Re: tag, and accessing the plugin list
Posted by Carlos Santana <cs...@gmail.com>.
+1
Yep I agree this way users can get list of plugins installed from
javascript pretty easy on all platforms from a web resource (i.e.
cordova_plugins.js
)
On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <ag...@chromium.org>wrote:
> That sounds good to me.
>
>
> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Looking back over all of this discussion, we have a growing trend of
> > dissatisfaction with the current config file setup. We've talked in the
> > past about moving to JSON format, Andrew is suggesting above replacing
> 99%
> > of <config-file> uses with specialized tags to inject permissions and
> > <feature>s, my summary in the other thread was pretty disgustingly
> > complicated, etc.
> >
> > I propose three things:
> > 1. Punt all discussion of overhauling configuration files to the new
> year.
> > 2. Drop my proposals above, as well as the summary Anis posted of last
> > night's discussion.
> > 3. Solve the immediate use-case of AppHarness wanting to know what
> plugins
> > are installed by injecting that object into a new key attached to the
> array
> > of JS modules in cordova_plugins.js.
> >
> > This modifies a file that is already clearly a build artifact and not
> > touched by humans. It is fully backward compatible, since the array of JS
> > modules is unchanged when viewed as an array. And it gets me access the
> > information I needed in the short term to build the AppHarness
> > functionality.
> >
> > How does that sound?
> >
> > Braden
> >
> >
> > On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > I think the thing that irks me about the proposal to fiddle with
> > > <feature>s, is that right now plugins put them in <config-file> tags.
> > With
> > > these tags:
> > >
> > > - You can specify any target that's an xml file
> > > - You can specify any xpath in the parent attribute
> > > - plugman will splice in your XML into the target file if-and-only-if
> > there
> > > wasn't already another plugin that spliced in the exact same chunk into
> > the
> > > exact same place.
> > >
> > > Now, we're proposing to make this <config-file> rule even more complex:
> > > - You can specify any target that's an xml file
> > > - You can specify any xpath in the parent attribute
> > > NEW:
> > > - If you specify target="config.xml" AND you specify parent xpath that
> > > evaluates to the same things as parent="/widget" Then:
> > > - For each top-level <feature> element in your payload:
> > > - Plugman will insert two new <params> into it with your plugin
> ID &
> > > version
> > > - plugman will splice in your XML into the target file if-and-only-if
> > there
> > > wasn't already another plugin that spliced in the exact same chunk into
> > the
> > > exact same place.
> > > NEW:
> > > - If your plugin does not have any <config-file> targets that match the
> > > above conditions:
> > > - Plugman will add one for you with a default payload of a <feature>
> > with
> > > params.
> > >
> > >
> > > I haven't run it past any real-world users, but it if it sounds
> > complicated
> > > to me, then I'd be surprised if it wasn't also confusing to others.
> > >
> > > Maybe a fallout of this discussion is that it's hurting us to be using
> > > <config-file> for common things. Seems like it would be simpler for
> both
> > > plugman and plugin devs to have <feature> outside of <config-file>. If
> > this
> > > were the case, I'd be much more open to the idea of altering them when
> we
> > > spliced them in.
> > >
> > > Going a step further, Michal suggested in another thread that we just
> > > include the plugin.xml files directly in apps. The more I think about
> > this,
> > > the more it makes sense to me. Why are we even splicing things into
> > > config.xml? Seems like we're doing work to lose information. If we just
> > > included the plugin.xml files directly, we could read out the
> <feature>,
> > > <access>, plugin iD & version, even <js-module>s. If we want to keep
> all
> > > the runtime xml in one file, how about splice in the entire plugin.xml
> > into
> > > config.xml?
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > > > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> So...
> > > > >>
> > > > >> We just had a good chat about this topic with Braden and Gorkem
> and
> > we
> > > > >> think that adding <param>s to the existing <feature> tag is better
> > > > >> than introducing a new one.
> > > > >>
> > > > >> Pros:
> > > > >> - No new tags, less confusion.
> > > > >
> > > > > Unless we're going to add a new tag to do what <feature> currently
> > > does,
> > > > > I'd argue having one tag that does two things is more confusing.
> > > >
> > > > As you say it's arguable but I tend to base my arguments on
> real-world
> > > > users rather than Cordova core developers.
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >
> > > > > - A good path towards having a unique top-level config.xml since we
> > > > >> can now identify which plugins are installed from the feature tag.
> > > > >> Therefore, we can better handle uninstalls and user edits to the
> > file.
> > > > >>
> > > > > This makes me think I just don't understand what the proposal now
> is.
> > > An
> > > > > example would help I think.
> > > > > Some questions:
> > > > > - Does this mean we're going to change <feature> to not directly
> > define
> > > > > bridge mappings?
> > > >
> > > > No
> > > >
> > > > > - Is the idea to have a new tag within <feature> that defines
> the
> > > > bridge
> > > > > binding?
> > > >
> > > > No
> > > >
> > > > > - If not:
> > > > > - what are we doing with plugins that define multiple <feature>
> > > tags?
> > > >
> > > > We define two <param>s that hold the plugin ID an version. In older
> > > > versions of cordova <feature> was called <plugin> and the mapping was
> > > > one-to-one and it still seems to be the case. If for whatever reason
> > > > one needs to have 2+ <feature>s for one plugin, all <feature> tags
> > > > should define <param>s that indicate ID/version.
> > > >
> > > > > - what are we doing if apps directly define <feature> tags
> > directly
> > > in
> > > > > their config.xml (outside of plugins)? This is still common for
> > plugins
> > > > > that haven't been updated to plugman. I think we do this for
> plugins
> > > > > bundled with the platforms (e.g. Android's App plugin)
> > > >
> > > > I am not sure I understand the question but everything gets defined
> in
> > > > the top-level config.xml (plugins, js-only plugins and
> > > > platform-specific things like Android's App plugin).
> > > >
> > > I just wanted to point out that people still copy & paste in <feature>
> > tags
> > > directly into their config.xml for plugins that haven't been
> > plugmanified.
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> Cons:
> > > > >> - Harder to implement for us. "Should still take less time than
> > > > >> arguing on the topic" said Braden ;-)
> > > > >> - Previous Cordova platforms might or might not choke when they
> see
> > > > >> JS-only plugins listed as <feature>s but it's unlikely.
> > > > >>
> > > > > Android chokes:
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
> > > >
> > > > Can you be specifc ? From what I read from PluginManager.java and
> > > > PluginEntry.java is that it gets added to a HashMap but the class
> only
> > > > gets instantiated if "onload" <param> is defined or if getPlugin() is
> > > > called when JS is called but exec not called for JS-only plugins
> > > > right?
> > > >
> > > Sorry, should have just tried it out before speaking up. I thought
> > adding a
> > > null key would be a problem, but it seems as though hash maps do allow
> > > them.
> > >
> > >
> > > > >
> > > > >
> > > > > Not sure if this was considered, but instead of using a config
> file,
> > we
> > > > > could generate a source file that gets compiled in. Would eliminate
> > any
> > > > > performance concerns and stay out of files that users might be
> > peering
> > > > at.
> > > >
> > > > Sure but this would only solve the app-harness problem we could also
> > > > solve at least two more problems:
> > > > - Have one canonical config.xml which is a path to making platforms
> > > > true build artifacts.
> > > > - Have the ability install all plugins all at once (ala npm install).
> > > >
> > > Good points. generating a source file == bad idea.
> > >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >>
> > > > >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> > > > >> <br...@chromium.org> wrote:
> > > > >> > Following up on my big config-and-metadata summary in the other
> > > > thread,
> > > > >> the
> > > > >> > file in question here is the platform config.xml (that is,
> > > > >> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> > > > >> > Significantly, this file is written by Plugman and CLI, and read
> > by
> > > > the
> > > > >> > native platform. The user never reads or writes this file
> directly
> > > in
> > > > the
> > > > >> > normal flow of things.
> > > > >> >
> > > > >> > Braden
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> > > > braden@chromium.org
> > > > >> >wrote:
> > > > >> >
> > > > >> >> There's a bit of a BC issue here because cordova.js needs to
> know
> > > > what
> > > > >> >> file to inject a <script> tag for, so it can load the file and
> > then
> > > > load
> > > > >> >> its module. That's why I hesitated to modify the format of that
> > > file,
> > > > >> >> originally. (It currently sets module.exports to an array of
> > > > <js-module>
> > > > >> >> info.) Like Andrew says, entirely possible to make the change,
> > just
> > > > that
> > > > >> >> some care is required.
> > > > >> >>
> > > > >> >> Braden
> > > > >> >>
> > > > >> >>
> > > > >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> > > > >> >> jbondc@gdesolutions.com> wrote:
> > > > >> >>
> > > > >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > > > >> >>> > I'm going to attempt to summarize in point form:
> > > > >> >>> >
> > > > >> >>> > Goal:
> > > > >> >>> > - Make available the list of installed plugins and their
> > > > versions to
> > > > >> >>> native side & JS
> > > > >> >>> > side.
> > > > >> >>> > - Needed by App Harness to know whether an app is
> compatible
> > > with
> > > > >> its
> > > > >> >>> > bundled set of plugins.
> > > > >> >>> >
> > > > >> >>> > Using cordova_plugins.js:
> > > > >> >>> > - It doesn't have the information that we need
> > > > >> >>> > - We could add the extra information, but not easily since
> > the
> > > > file
> > > > >> >>> exports an
> > > > >> >>> > array instead of an object.
> > > > >> >>> > - This file is not currently parsed by the native layer, so
> > > > having
> > > > >> the
> > > > >> >>> info here
> > > > >> >>> > would be an extra IO on start-up.
> > > > >> >>> >
> > > > >> >>>
> > > > >> >>> Great summary :)
> > > > >> >>>
> > > > >> >>> Is it difficult to rename ' cordova_plugins.js' to something
> > more
> > > > broad
> > > > >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and
> > > > using an
> > > > >> >>> object?
> > > > >> >>> Since it's generated code, first impression is there's no BC
> > issue
> > > > >> other
> > > > >> >>> than doing another prepare.
> > > > >> >>>
> > > > >> >>> Doesn't seem like there's a way to avoid the extra IO on the
> > > native
> > > > >> side
> > > > >> >>> (e.g. cordova_meta.js). If the detailed list of installed
> > plugins
> > > > is in
> > > > >> >>> xml, how will the JS side access it?
> > > > >> >>>
> > > > >> >>> Broader problem is there's no single cordova meta file that's
> > > shared
> > > > >> >>> between native & js. Considering that on some platforms,
> there's
> > > > only
> > > > >> >>> JavaScript, putting the information in JSON seems like a good
> > > move.
> > > > >> >>>
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: tag, and accessing the plugin list
Posted by Andrew Grieve <ag...@chromium.org>.
That sounds good to me.
On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <br...@chromium.org>wrote:
> Looking back over all of this discussion, we have a growing trend of
> dissatisfaction with the current config file setup. We've talked in the
> past about moving to JSON format, Andrew is suggesting above replacing 99%
> of <config-file> uses with specialized tags to inject permissions and
> <feature>s, my summary in the other thread was pretty disgustingly
> complicated, etc.
>
> I propose three things:
> 1. Punt all discussion of overhauling configuration files to the new year.
> 2. Drop my proposals above, as well as the summary Anis posted of last
> night's discussion.
> 3. Solve the immediate use-case of AppHarness wanting to know what plugins
> are installed by injecting that object into a new key attached to the array
> of JS modules in cordova_plugins.js.
>
> This modifies a file that is already clearly a build artifact and not
> touched by humans. It is fully backward compatible, since the array of JS
> modules is unchanged when viewed as an array. And it gets me access the
> information I needed in the short term to build the AppHarness
> functionality.
>
> How does that sound?
>
> Braden
>
>
> On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I think the thing that irks me about the proposal to fiddle with
> > <feature>s, is that right now plugins put them in <config-file> tags.
> With
> > these tags:
> >
> > - You can specify any target that's an xml file
> > - You can specify any xpath in the parent attribute
> > - plugman will splice in your XML into the target file if-and-only-if
> there
> > wasn't already another plugin that spliced in the exact same chunk into
> the
> > exact same place.
> >
> > Now, we're proposing to make this <config-file> rule even more complex:
> > - You can specify any target that's an xml file
> > - You can specify any xpath in the parent attribute
> > NEW:
> > - If you specify target="config.xml" AND you specify parent xpath that
> > evaluates to the same things as parent="/widget" Then:
> > - For each top-level <feature> element in your payload:
> > - Plugman will insert two new <params> into it with your plugin ID &
> > version
> > - plugman will splice in your XML into the target file if-and-only-if
> there
> > wasn't already another plugin that spliced in the exact same chunk into
> the
> > exact same place.
> > NEW:
> > - If your plugin does not have any <config-file> targets that match the
> > above conditions:
> > - Plugman will add one for you with a default payload of a <feature>
> with
> > params.
> >
> >
> > I haven't run it past any real-world users, but it if it sounds
> complicated
> > to me, then I'd be surprised if it wasn't also confusing to others.
> >
> > Maybe a fallout of this discussion is that it's hurting us to be using
> > <config-file> for common things. Seems like it would be simpler for both
> > plugman and plugin devs to have <feature> outside of <config-file>. If
> this
> > were the case, I'd be much more open to the idea of altering them when we
> > spliced them in.
> >
> > Going a step further, Michal suggested in another thread that we just
> > include the plugin.xml files directly in apps. The more I think about
> this,
> > the more it makes sense to me. Why are we even splicing things into
> > config.xml? Seems like we're doing work to lose information. If we just
> > included the plugin.xml files directly, we could read out the <feature>,
> > <access>, plugin iD & version, even <js-module>s. If we want to keep all
> > the runtime xml in one file, how about splice in the entire plugin.xml
> into
> > config.xml?
> >
> >
> >
> >
> >
> > On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> > > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com>
> > > wrote:
> > > >
> > > >> So...
> > > >>
> > > >> We just had a good chat about this topic with Braden and Gorkem and
> we
> > > >> think that adding <param>s to the existing <feature> tag is better
> > > >> than introducing a new one.
> > > >>
> > > >> Pros:
> > > >> - No new tags, less confusion.
> > > >
> > > > Unless we're going to add a new tag to do what <feature> currently
> > does,
> > > > I'd argue having one tag that does two things is more confusing.
> > >
> > > As you say it's arguable but I tend to base my arguments on real-world
> > > users rather than Cordova core developers.
> > >
> > > >
> > > >
> > > >>
> > > >
> > > > - A good path towards having a unique top-level config.xml since we
> > > >> can now identify which plugins are installed from the feature tag.
> > > >> Therefore, we can better handle uninstalls and user edits to the
> file.
> > > >>
> > > > This makes me think I just don't understand what the proposal now is.
> > An
> > > > example would help I think.
> > > > Some questions:
> > > > - Does this mean we're going to change <feature> to not directly
> define
> > > > bridge mappings?
> > >
> > > No
> > >
> > > > - Is the idea to have a new tag within <feature> that defines the
> > > bridge
> > > > binding?
> > >
> > > No
> > >
> > > > - If not:
> > > > - what are we doing with plugins that define multiple <feature>
> > tags?
> > >
> > > We define two <param>s that hold the plugin ID an version. In older
> > > versions of cordova <feature> was called <plugin> and the mapping was
> > > one-to-one and it still seems to be the case. If for whatever reason
> > > one needs to have 2+ <feature>s for one plugin, all <feature> tags
> > > should define <param>s that indicate ID/version.
> > >
> > > > - what are we doing if apps directly define <feature> tags
> directly
> > in
> > > > their config.xml (outside of plugins)? This is still common for
> plugins
> > > > that haven't been updated to plugman. I think we do this for plugins
> > > > bundled with the platforms (e.g. Android's App plugin)
> > >
> > > I am not sure I understand the question but everything gets defined in
> > > the top-level config.xml (plugins, js-only plugins and
> > > platform-specific things like Android's App plugin).
> > >
> > I just wanted to point out that people still copy & paste in <feature>
> tags
> > directly into their config.xml for plugins that haven't been
> plugmanified.
> >
> >
> >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >> Cons:
> > > >> - Harder to implement for us. "Should still take less time than
> > > >> arguing on the topic" said Braden ;-)
> > > >> - Previous Cordova platforms might or might not choke when they see
> > > >> JS-only plugins listed as <feature>s but it's unlikely.
> > > >>
> > > > Android chokes:
> > > >
> > >
> >
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
> > >
> > > Can you be specifc ? From what I read from PluginManager.java and
> > > PluginEntry.java is that it gets added to a HashMap but the class only
> > > gets instantiated if "onload" <param> is defined or if getPlugin() is
> > > called when JS is called but exec not called for JS-only plugins
> > > right?
> > >
> > Sorry, should have just tried it out before speaking up. I thought
> adding a
> > null key would be a problem, but it seems as though hash maps do allow
> > them.
> >
> >
> > > >
> > > >
> > > > Not sure if this was considered, but instead of using a config file,
> we
> > > > could generate a source file that gets compiled in. Would eliminate
> any
> > > > performance concerns and stay out of files that users might be
> peering
> > > at.
> > >
> > > Sure but this would only solve the app-harness problem we could also
> > > solve at least two more problems:
> > > - Have one canonical config.xml which is a path to making platforms
> > > true build artifacts.
> > > - Have the ability install all plugins all at once (ala npm install).
> > >
> > Good points. generating a source file == bad idea.
> >
> >
> >
> > >
> > >
> > > >
> > > >
> > > >>
> > > >>
> > > >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> > > >> <br...@chromium.org> wrote:
> > > >> > Following up on my big config-and-metadata summary in the other
> > > thread,
> > > >> the
> > > >> > file in question here is the platform config.xml (that is,
> > > >> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> > > >> > Significantly, this file is written by Plugman and CLI, and read
> by
> > > the
> > > >> > native platform. The user never reads or writes this file directly
> > in
> > > the
> > > >> > normal flow of things.
> > > >> >
> > > >> > Braden
> > > >> >
> > > >> >
> > > >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> > > braden@chromium.org
> > > >> >wrote:
> > > >> >
> > > >> >> There's a bit of a BC issue here because cordova.js needs to know
> > > what
> > > >> >> file to inject a <script> tag for, so it can load the file and
> then
> > > load
> > > >> >> its module. That's why I hesitated to modify the format of that
> > file,
> > > >> >> originally. (It currently sets module.exports to an array of
> > > <js-module>
> > > >> >> info.) Like Andrew says, entirely possible to make the change,
> just
> > > that
> > > >> >> some care is required.
> > > >> >>
> > > >> >> Braden
> > > >> >>
> > > >> >>
> > > >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> > > >> >> jbondc@gdesolutions.com> wrote:
> > > >> >>
> > > >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > > >> >>> > I'm going to attempt to summarize in point form:
> > > >> >>> >
> > > >> >>> > Goal:
> > > >> >>> > - Make available the list of installed plugins and their
> > > versions to
> > > >> >>> native side & JS
> > > >> >>> > side.
> > > >> >>> > - Needed by App Harness to know whether an app is compatible
> > with
> > > >> its
> > > >> >>> > bundled set of plugins.
> > > >> >>> >
> > > >> >>> > Using cordova_plugins.js:
> > > >> >>> > - It doesn't have the information that we need
> > > >> >>> > - We could add the extra information, but not easily since
> the
> > > file
> > > >> >>> exports an
> > > >> >>> > array instead of an object.
> > > >> >>> > - This file is not currently parsed by the native layer, so
> > > having
> > > >> the
> > > >> >>> info here
> > > >> >>> > would be an extra IO on start-up.
> > > >> >>> >
> > > >> >>>
> > > >> >>> Great summary :)
> > > >> >>>
> > > >> >>> Is it difficult to rename ' cordova_plugins.js' to something
> more
> > > broad
> > > >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and
> > > using an
> > > >> >>> object?
> > > >> >>> Since it's generated code, first impression is there's no BC
> issue
> > > >> other
> > > >> >>> than doing another prepare.
> > > >> >>>
> > > >> >>> Doesn't seem like there's a way to avoid the extra IO on the
> > native
> > > >> side
> > > >> >>> (e.g. cordova_meta.js). If the detailed list of installed
> plugins
> > > is in
> > > >> >>> xml, how will the JS side access it?
> > > >> >>>
> > > >> >>> Broader problem is there's no single cordova meta file that's
> > shared
> > > >> >>> between native & js. Considering that on some platforms, there's
> > > only
> > > >> >>> JavaScript, putting the information in JSON seems like a good
> > move.
> > > >> >>>
> > > >> >>>
> > > >> >>
> > > >>
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
Brian, I'm definitely interested in overhauling the configuration files.
The reason I suggested punting, however, is that I and the Google team are
chasing a launch milestone for the next few weeks. I would have much more
time for drawing up ideas, discussing them, and implementing them starting
in Q1. I realize that only applies to me, though, and if people want to
start that discussion soon, then I'll contribute to it. I have several
ideas in that direction, if we're going to do a wholesale change to our
configuration setup.
Braden
On Fri, Nov 15, 2013 at 5:29 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Fri, Nov 15, 2013 at 4:25 PM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
> > > I propose three things:
> > > 1. Punt all discussion of overhauling configuration files to the new
> > year.
> > > 2. Drop my proposals above, as well as the summary Anis posted of last
> > night's
> > > discussion.
> > > 3. Solve the immediate use-case of AppHarness wanting to know what
> > plugins
> > > are installed by injecting that object into a new key attached to the
> > array of JS
> > > modules in cordova_plugins.js.
> > >
> >
> > +1
> >
> > Added info about 'cordova_plugins.js' here:
> > https://wiki.apache.org/cordova/ConfigurationFiles
> >
> > Small note to avoid confusion: the naming of the file is a bit
> misleading,
> > 'cordova_modules.js' is more appropriate. Since each plugin can have 1+
> > modules.
> >
> > Eventually might better to rename this altogether to ~
> > 'cordova_meta.js(on)' that holds generated metadata their either native
> or
> > JavaScript can read.
> >
> > Thats a good observation re modules not plugins, but with Bradens change
> to add the list of plugins I think the name becomes less invalid. Either
> way, not worth the change since its just an artifact the user never opens
> directly.
>
Re: tag, and accessing the plugin list
Posted by Michal Mocny <mm...@chromium.org>.
On Fri, Nov 15, 2013 at 4:25 PM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
> > I propose three things:
> > 1. Punt all discussion of overhauling configuration files to the new
> year.
> > 2. Drop my proposals above, as well as the summary Anis posted of last
> night's
> > discussion.
> > 3. Solve the immediate use-case of AppHarness wanting to know what
> plugins
> > are installed by injecting that object into a new key attached to the
> array of JS
> > modules in cordova_plugins.js.
> >
>
> +1
>
> Added info about 'cordova_plugins.js' here:
> https://wiki.apache.org/cordova/ConfigurationFiles
>
> Small note to avoid confusion: the naming of the file is a bit misleading,
> 'cordova_modules.js' is more appropriate. Since each plugin can have 1+
> modules.
>
> Eventually might better to rename this altogether to ~
> 'cordova_meta.js(on)' that holds generated metadata their either native or
> JavaScript can read.
>
> Thats a good observation re modules not plugins, but with Bradens change
to add the list of plugins I think the name becomes less invalid. Either
way, not worth the change since its just an artifact the user never opens
directly.
RE: tag, and accessing the plugin list
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
> I propose three things:
> 1. Punt all discussion of overhauling configuration files to the new year.
> 2. Drop my proposals above, as well as the summary Anis posted of last night's
> discussion.
> 3. Solve the immediate use-case of AppHarness wanting to know what plugins
> are installed by injecting that object into a new key attached to the array of JS
> modules in cordova_plugins.js.
>
+1
Added info about 'cordova_plugins.js' here:
https://wiki.apache.org/cordova/ConfigurationFiles
Small note to avoid confusion: the naming of the file is a bit misleading, 'cordova_modules.js' is more appropriate. Since each plugin can have 1+ modules.
Eventually might better to rename this altogether to ~ 'cordova_meta.js(on)' that holds generated metadata their either native or JavaScript can read.
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
Looking back over all of this discussion, we have a growing trend of
dissatisfaction with the current config file setup. We've talked in the
past about moving to JSON format, Andrew is suggesting above replacing 99%
of <config-file> uses with specialized tags to inject permissions and
<feature>s, my summary in the other thread was pretty disgustingly
complicated, etc.
I propose three things:
1. Punt all discussion of overhauling configuration files to the new year.
2. Drop my proposals above, as well as the summary Anis posted of last
night's discussion.
3. Solve the immediate use-case of AppHarness wanting to know what plugins
are installed by injecting that object into a new key attached to the array
of JS modules in cordova_plugins.js.
This modifies a file that is already clearly a build artifact and not
touched by humans. It is fully backward compatible, since the array of JS
modules is unchanged when viewed as an array. And it gets me access the
information I needed in the short term to build the AppHarness
functionality.
How does that sound?
Braden
On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <ag...@chromium.org>wrote:
> I think the thing that irks me about the proposal to fiddle with
> <feature>s, is that right now plugins put them in <config-file> tags. With
> these tags:
>
> - You can specify any target that's an xml file
> - You can specify any xpath in the parent attribute
> - plugman will splice in your XML into the target file if-and-only-if there
> wasn't already another plugin that spliced in the exact same chunk into the
> exact same place.
>
> Now, we're proposing to make this <config-file> rule even more complex:
> - You can specify any target that's an xml file
> - You can specify any xpath in the parent attribute
> NEW:
> - If you specify target="config.xml" AND you specify parent xpath that
> evaluates to the same things as parent="/widget" Then:
> - For each top-level <feature> element in your payload:
> - Plugman will insert two new <params> into it with your plugin ID &
> version
> - plugman will splice in your XML into the target file if-and-only-if there
> wasn't already another plugin that spliced in the exact same chunk into the
> exact same place.
> NEW:
> - If your plugin does not have any <config-file> targets that match the
> above conditions:
> - Plugman will add one for you with a default payload of a <feature> with
> params.
>
>
> I haven't run it past any real-world users, but it if it sounds complicated
> to me, then I'd be surprised if it wasn't also confusing to others.
>
> Maybe a fallout of this discussion is that it's hurting us to be using
> <config-file> for common things. Seems like it would be simpler for both
> plugman and plugin devs to have <feature> outside of <config-file>. If this
> were the case, I'd be much more open to the idea of altering them when we
> spliced them in.
>
> Going a step further, Michal suggested in another thread that we just
> include the plugin.xml files directly in apps. The more I think about this,
> the more it makes sense to me. Why are we even splicing things into
> config.xml? Seems like we're doing work to lose information. If we just
> included the plugin.xml files directly, we could read out the <feature>,
> <access>, plugin iD & version, even <js-module>s. If we want to keep all
> the runtime xml in one file, how about splice in the entire plugin.xml into
> config.xml?
>
>
>
>
>
> On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > >> So...
> > >>
> > >> We just had a good chat about this topic with Braden and Gorkem and we
> > >> think that adding <param>s to the existing <feature> tag is better
> > >> than introducing a new one.
> > >>
> > >> Pros:
> > >> - No new tags, less confusion.
> > >
> > > Unless we're going to add a new tag to do what <feature> currently
> does,
> > > I'd argue having one tag that does two things is more confusing.
> >
> > As you say it's arguable but I tend to base my arguments on real-world
> > users rather than Cordova core developers.
> >
> > >
> > >
> > >>
> > >
> > > - A good path towards having a unique top-level config.xml since we
> > >> can now identify which plugins are installed from the feature tag.
> > >> Therefore, we can better handle uninstalls and user edits to the file.
> > >>
> > > This makes me think I just don't understand what the proposal now is.
> An
> > > example would help I think.
> > > Some questions:
> > > - Does this mean we're going to change <feature> to not directly define
> > > bridge mappings?
> >
> > No
> >
> > > - Is the idea to have a new tag within <feature> that defines the
> > bridge
> > > binding?
> >
> > No
> >
> > > - If not:
> > > - what are we doing with plugins that define multiple <feature>
> tags?
> >
> > We define two <param>s that hold the plugin ID an version. In older
> > versions of cordova <feature> was called <plugin> and the mapping was
> > one-to-one and it still seems to be the case. If for whatever reason
> > one needs to have 2+ <feature>s for one plugin, all <feature> tags
> > should define <param>s that indicate ID/version.
> >
> > > - what are we doing if apps directly define <feature> tags directly
> in
> > > their config.xml (outside of plugins)? This is still common for plugins
> > > that haven't been updated to plugman. I think we do this for plugins
> > > bundled with the platforms (e.g. Android's App plugin)
> >
> > I am not sure I understand the question but everything gets defined in
> > the top-level config.xml (plugins, js-only plugins and
> > platform-specific things like Android's App plugin).
> >
> I just wanted to point out that people still copy & paste in <feature> tags
> directly into their config.xml for plugins that haven't been plugmanified.
>
>
>
> >
> > >
> > >
> > >
> > >
> > >>
> > >> Cons:
> > >> - Harder to implement for us. "Should still take less time than
> > >> arguing on the topic" said Braden ;-)
> > >> - Previous Cordova platforms might or might not choke when they see
> > >> JS-only plugins listed as <feature>s but it's unlikely.
> > >>
> > > Android chokes:
> > >
> >
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
> >
> > Can you be specifc ? From what I read from PluginManager.java and
> > PluginEntry.java is that it gets added to a HashMap but the class only
> > gets instantiated if "onload" <param> is defined or if getPlugin() is
> > called when JS is called but exec not called for JS-only plugins
> > right?
> >
> Sorry, should have just tried it out before speaking up. I thought adding a
> null key would be a problem, but it seems as though hash maps do allow
> them.
>
>
> > >
> > >
> > > Not sure if this was considered, but instead of using a config file, we
> > > could generate a source file that gets compiled in. Would eliminate any
> > > performance concerns and stay out of files that users might be peering
> > at.
> >
> > Sure but this would only solve the app-harness problem we could also
> > solve at least two more problems:
> > - Have one canonical config.xml which is a path to making platforms
> > true build artifacts.
> > - Have the ability install all plugins all at once (ala npm install).
> >
> Good points. generating a source file == bad idea.
>
>
>
> >
> >
> > >
> > >
> > >>
> > >>
> > >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> > >> <br...@chromium.org> wrote:
> > >> > Following up on my big config-and-metadata summary in the other
> > thread,
> > >> the
> > >> > file in question here is the platform config.xml (that is,
> > >> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> > >> > Significantly, this file is written by Plugman and CLI, and read by
> > the
> > >> > native platform. The user never reads or writes this file directly
> in
> > the
> > >> > normal flow of things.
> > >> >
> > >> > Braden
> > >> >
> > >> >
> > >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> > braden@chromium.org
> > >> >wrote:
> > >> >
> > >> >> There's a bit of a BC issue here because cordova.js needs to know
> > what
> > >> >> file to inject a <script> tag for, so it can load the file and then
> > load
> > >> >> its module. That's why I hesitated to modify the format of that
> file,
> > >> >> originally. (It currently sets module.exports to an array of
> > <js-module>
> > >> >> info.) Like Andrew says, entirely possible to make the change, just
> > that
> > >> >> some care is required.
> > >> >>
> > >> >> Braden
> > >> >>
> > >> >>
> > >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> > >> >> jbondc@gdesolutions.com> wrote:
> > >> >>
> > >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > >> >>> > I'm going to attempt to summarize in point form:
> > >> >>> >
> > >> >>> > Goal:
> > >> >>> > - Make available the list of installed plugins and their
> > versions to
> > >> >>> native side & JS
> > >> >>> > side.
> > >> >>> > - Needed by App Harness to know whether an app is compatible
> with
> > >> its
> > >> >>> > bundled set of plugins.
> > >> >>> >
> > >> >>> > Using cordova_plugins.js:
> > >> >>> > - It doesn't have the information that we need
> > >> >>> > - We could add the extra information, but not easily since the
> > file
> > >> >>> exports an
> > >> >>> > array instead of an object.
> > >> >>> > - This file is not currently parsed by the native layer, so
> > having
> > >> the
> > >> >>> info here
> > >> >>> > would be an extra IO on start-up.
> > >> >>> >
> > >> >>>
> > >> >>> Great summary :)
> > >> >>>
> > >> >>> Is it difficult to rename ' cordova_plugins.js' to something more
> > broad
> > >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and
> > using an
> > >> >>> object?
> > >> >>> Since it's generated code, first impression is there's no BC issue
> > >> other
> > >> >>> than doing another prepare.
> > >> >>>
> > >> >>> Doesn't seem like there's a way to avoid the extra IO on the
> native
> > >> side
> > >> >>> (e.g. cordova_meta.js). If the detailed list of installed plugins
> > is in
> > >> >>> xml, how will the JS side access it?
> > >> >>>
> > >> >>> Broader problem is there's no single cordova meta file that's
> shared
> > >> >>> between native & js. Considering that on some platforms, there's
> > only
> > >> >>> JavaScript, putting the information in JSON seems like a good
> move.
> > >> >>>
> > >> >>>
> > >> >>
> > >>
> >
>
Re: tag, and accessing the plugin list
Posted by Andrew Grieve <ag...@chromium.org>.
I think the thing that irks me about the proposal to fiddle with
<feature>s, is that right now plugins put them in <config-file> tags. With
these tags:
- You can specify any target that's an xml file
- You can specify any xpath in the parent attribute
- plugman will splice in your XML into the target file if-and-only-if there
wasn't already another plugin that spliced in the exact same chunk into the
exact same place.
Now, we're proposing to make this <config-file> rule even more complex:
- You can specify any target that's an xml file
- You can specify any xpath in the parent attribute
NEW:
- If you specify target="config.xml" AND you specify parent xpath that
evaluates to the same things as parent="/widget" Then:
- For each top-level <feature> element in your payload:
- Plugman will insert two new <params> into it with your plugin ID &
version
- plugman will splice in your XML into the target file if-and-only-if there
wasn't already another plugin that spliced in the exact same chunk into the
exact same place.
NEW:
- If your plugin does not have any <config-file> targets that match the
above conditions:
- Plugman will add one for you with a default payload of a <feature> with
params.
I haven't run it past any real-world users, but it if it sounds complicated
to me, then I'd be surprised if it wasn't also confusing to others.
Maybe a fallout of this discussion is that it's hurting us to be using
<config-file> for common things. Seems like it would be simpler for both
plugman and plugin devs to have <feature> outside of <config-file>. If this
were the case, I'd be much more open to the idea of altering them when we
spliced them in.
Going a step further, Michal suggested in another thread that we just
include the plugin.xml files directly in apps. The more I think about this,
the more it makes sense to me. Why are we even splicing things into
config.xml? Seems like we're doing work to lose information. If we just
included the plugin.xml files directly, we could read out the <feature>,
<access>, plugin iD & version, even <js-module>s. If we want to keep all
the runtime xml in one file, how about splice in the entire plugin.xml into
config.xml?
On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <an...@gmail.com> wrote:
> On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> >> So...
> >>
> >> We just had a good chat about this topic with Braden and Gorkem and we
> >> think that adding <param>s to the existing <feature> tag is better
> >> than introducing a new one.
> >>
> >> Pros:
> >> - No new tags, less confusion.
> >
> > Unless we're going to add a new tag to do what <feature> currently does,
> > I'd argue having one tag that does two things is more confusing.
>
> As you say it's arguable but I tend to base my arguments on real-world
> users rather than Cordova core developers.
>
> >
> >
> >>
> >
> > - A good path towards having a unique top-level config.xml since we
> >> can now identify which plugins are installed from the feature tag.
> >> Therefore, we can better handle uninstalls and user edits to the file.
> >>
> > This makes me think I just don't understand what the proposal now is. An
> > example would help I think.
> > Some questions:
> > - Does this mean we're going to change <feature> to not directly define
> > bridge mappings?
>
> No
>
> > - Is the idea to have a new tag within <feature> that defines the
> bridge
> > binding?
>
> No
>
> > - If not:
> > - what are we doing with plugins that define multiple <feature> tags?
>
> We define two <param>s that hold the plugin ID an version. In older
> versions of cordova <feature> was called <plugin> and the mapping was
> one-to-one and it still seems to be the case. If for whatever reason
> one needs to have 2+ <feature>s for one plugin, all <feature> tags
> should define <param>s that indicate ID/version.
>
> > - what are we doing if apps directly define <feature> tags directly in
> > their config.xml (outside of plugins)? This is still common for plugins
> > that haven't been updated to plugman. I think we do this for plugins
> > bundled with the platforms (e.g. Android's App plugin)
>
> I am not sure I understand the question but everything gets defined in
> the top-level config.xml (plugins, js-only plugins and
> platform-specific things like Android's App plugin).
>
I just wanted to point out that people still copy & paste in <feature> tags
directly into their config.xml for plugins that haven't been plugmanified.
>
> >
> >
> >
> >
> >>
> >> Cons:
> >> - Harder to implement for us. "Should still take less time than
> >> arguing on the topic" said Braden ;-)
> >> - Previous Cordova platforms might or might not choke when they see
> >> JS-only plugins listed as <feature>s but it's unlikely.
> >>
> > Android chokes:
> >
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
>
> Can you be specifc ? From what I read from PluginManager.java and
> PluginEntry.java is that it gets added to a HashMap but the class only
> gets instantiated if "onload" <param> is defined or if getPlugin() is
> called when JS is called but exec not called for JS-only plugins
> right?
>
Sorry, should have just tried it out before speaking up. I thought adding a
null key would be a problem, but it seems as though hash maps do allow them.
> >
> >
> > Not sure if this was considered, but instead of using a config file, we
> > could generate a source file that gets compiled in. Would eliminate any
> > performance concerns and stay out of files that users might be peering
> at.
>
> Sure but this would only solve the app-harness problem we could also
> solve at least two more problems:
> - Have one canonical config.xml which is a path to making platforms
> true build artifacts.
> - Have the ability install all plugins all at once (ala npm install).
>
Good points. generating a source file == bad idea.
>
>
> >
> >
> >>
> >>
> >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> >> <br...@chromium.org> wrote:
> >> > Following up on my big config-and-metadata summary in the other
> thread,
> >> the
> >> > file in question here is the platform config.xml (that is,
> >> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> >> > Significantly, this file is written by Plugman and CLI, and read by
> the
> >> > native platform. The user never reads or writes this file directly in
> the
> >> > normal flow of things.
> >> >
> >> > Braden
> >> >
> >> >
> >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <
> braden@chromium.org
> >> >wrote:
> >> >
> >> >> There's a bit of a BC issue here because cordova.js needs to know
> what
> >> >> file to inject a <script> tag for, so it can load the file and then
> load
> >> >> its module. That's why I hesitated to modify the format of that file,
> >> >> originally. (It currently sets module.exports to an array of
> <js-module>
> >> >> info.) Like Andrew says, entirely possible to make the change, just
> that
> >> >> some care is required.
> >> >>
> >> >> Braden
> >> >>
> >> >>
> >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> >> >> jbondc@gdesolutions.com> wrote:
> >> >>
> >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> >> >>> > I'm going to attempt to summarize in point form:
> >> >>> >
> >> >>> > Goal:
> >> >>> > - Make available the list of installed plugins and their
> versions to
> >> >>> native side & JS
> >> >>> > side.
> >> >>> > - Needed by App Harness to know whether an app is compatible with
> >> its
> >> >>> > bundled set of plugins.
> >> >>> >
> >> >>> > Using cordova_plugins.js:
> >> >>> > - It doesn't have the information that we need
> >> >>> > - We could add the extra information, but not easily since the
> file
> >> >>> exports an
> >> >>> > array instead of an object.
> >> >>> > - This file is not currently parsed by the native layer, so
> having
> >> the
> >> >>> info here
> >> >>> > would be an extra IO on start-up.
> >> >>> >
> >> >>>
> >> >>> Great summary :)
> >> >>>
> >> >>> Is it difficult to rename ' cordova_plugins.js' to something more
> broad
> >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and
> using an
> >> >>> object?
> >> >>> Since it's generated code, first impression is there's no BC issue
> >> other
> >> >>> than doing another prepare.
> >> >>>
> >> >>> Doesn't seem like there's a way to avoid the extra IO on the native
> >> side
> >> >>> (e.g. cordova_meta.js). If the detailed list of installed plugins
> is in
> >> >>> xml, how will the JS side access it?
> >> >>>
> >> >>> Broader problem is there's no single cordova meta file that's shared
> >> >>> between native & js. Considering that on some platforms, there's
> only
> >> >>> JavaScript, putting the information in JSON seems like a good move.
> >> >>>
> >> >>>
> >> >>
> >>
>
Re: tag, and accessing the plugin list
Posted by Marcel Kinard <cm...@gmail.com>.
So does this mean that it would look something like this (in the case of the device plugin on android)?
<feature name="Device" >
<param name="android-package" value="org.apache.cordova.device.Device"/>
<param name="feature-id" value="org.apache.cordova.device"/>
<param name="feature-version" value="0.2.5"/>
</feature>
On Nov 14, 2013, at 11:19 PM, Anis KADRI <an...@gmail.com> wrote:
> We define two <param>s that hold the plugin ID an version. In older
> versions of cordova <feature> was called <plugin> and the mapping was
> one-to-one and it still seems to be the case. If for whatever reason
> one needs to have 2+ <feature>s for one plugin, all <feature> tags
> should define <param>s that indicate ID/version.
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com> wrote:
>
>> So...
>>
>> We just had a good chat about this topic with Braden and Gorkem and we
>> think that adding <param>s to the existing <feature> tag is better
>> than introducing a new one.
>>
>> Pros:
>> - No new tags, less confusion.
>
> Unless we're going to add a new tag to do what <feature> currently does,
> I'd argue having one tag that does two things is more confusing.
As you say it's arguable but I tend to base my arguments on real-world
users rather than Cordova core developers.
>
>
>>
>
> - A good path towards having a unique top-level config.xml since we
>> can now identify which plugins are installed from the feature tag.
>> Therefore, we can better handle uninstalls and user edits to the file.
>>
> This makes me think I just don't understand what the proposal now is. An
> example would help I think.
> Some questions:
> - Does this mean we're going to change <feature> to not directly define
> bridge mappings?
No
> - Is the idea to have a new tag within <feature> that defines the bridge
> binding?
No
> - If not:
> - what are we doing with plugins that define multiple <feature> tags?
We define two <param>s that hold the plugin ID an version. In older
versions of cordova <feature> was called <plugin> and the mapping was
one-to-one and it still seems to be the case. If for whatever reason
one needs to have 2+ <feature>s for one plugin, all <feature> tags
should define <param>s that indicate ID/version.
> - what are we doing if apps directly define <feature> tags directly in
> their config.xml (outside of plugins)? This is still common for plugins
> that haven't been updated to plugman. I think we do this for plugins
> bundled with the platforms (e.g. Android's App plugin)
I am not sure I understand the question but everything gets defined in
the top-level config.xml (plugins, js-only plugins and
platform-specific things like Android's App plugin).
>
>
>
>
>>
>> Cons:
>> - Harder to implement for us. "Should still take less time than
>> arguing on the topic" said Braden ;-)
>> - Previous Cordova platforms might or might not choke when they see
>> JS-only plugins listed as <feature>s but it's unlikely.
>>
> Android chokes:
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
Can you be specifc ? From what I read from PluginManager.java and
PluginEntry.java is that it gets added to a HashMap but the class only
gets instantiated if "onload" <param> is defined or if getPlugin() is
called when JS is called but exec not called for JS-only plugins
right?
>
>
> Not sure if this was considered, but instead of using a config file, we
> could generate a source file that gets compiled in. Would eliminate any
> performance concerns and stay out of files that users might be peering at.
Sure but this would only solve the app-harness problem we could also
solve at least two more problems:
- Have one canonical config.xml which is a path to making platforms
true build artifacts.
- Have the ability install all plugins all at once (ala npm install).
>
>
>>
>>
>> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
>> <br...@chromium.org> wrote:
>> > Following up on my big config-and-metadata summary in the other thread,
>> the
>> > file in question here is the platform config.xml (that is,
>> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
>> > Significantly, this file is written by Plugman and CLI, and read by the
>> > native platform. The user never reads or writes this file directly in the
>> > normal flow of things.
>> >
>> > Braden
>> >
>> >
>> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <braden@chromium.org
>> >wrote:
>> >
>> >> There's a bit of a BC issue here because cordova.js needs to know what
>> >> file to inject a <script> tag for, so it can load the file and then load
>> >> its module. That's why I hesitated to modify the format of that file,
>> >> originally. (It currently sets module.exports to an array of <js-module>
>> >> info.) Like Andrew says, entirely possible to make the change, just that
>> >> some care is required.
>> >>
>> >> Braden
>> >>
>> >>
>> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
>> >> jbondc@gdesolutions.com> wrote:
>> >>
>> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
>> >>> > I'm going to attempt to summarize in point form:
>> >>> >
>> >>> > Goal:
>> >>> > - Make available the list of installed plugins and their versions to
>> >>> native side & JS
>> >>> > side.
>> >>> > - Needed by App Harness to know whether an app is compatible with
>> its
>> >>> > bundled set of plugins.
>> >>> >
>> >>> > Using cordova_plugins.js:
>> >>> > - It doesn't have the information that we need
>> >>> > - We could add the extra information, but not easily since the file
>> >>> exports an
>> >>> > array instead of an object.
>> >>> > - This file is not currently parsed by the native layer, so having
>> the
>> >>> info here
>> >>> > would be an extra IO on start-up.
>> >>> >
>> >>>
>> >>> Great summary :)
>> >>>
>> >>> Is it difficult to rename ' cordova_plugins.js' to something more broad
>> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
>> >>> object?
>> >>> Since it's generated code, first impression is there's no BC issue
>> other
>> >>> than doing another prepare.
>> >>>
>> >>> Doesn't seem like there's a way to avoid the extra IO on the native
>> side
>> >>> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
>> >>> xml, how will the JS side access it?
>> >>>
>> >>> Broader problem is there's no single cordova meta file that's shared
>> >>> between native & js. Considering that on some platforms, there's only
>> >>> JavaScript, putting the information in JSON seems like a good move.
>> >>>
>> >>>
>> >>
>>
Re: tag, and accessing the plugin list
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <an...@gmail.com> wrote:
> So...
>
> We just had a good chat about this topic with Braden and Gorkem and we
> think that adding <param>s to the existing <feature> tag is better
> than introducing a new one.
>
> Pros:
> - No new tags, less confusion.
Unless we're going to add a new tag to do what <feature> currently does,
I'd argue having one tag that does two things is more confusing.
>
- A good path towards having a unique top-level config.xml since we
> can now identify which plugins are installed from the feature tag.
> Therefore, we can better handle uninstalls and user edits to the file.
>
This makes me think I just don't understand what the proposal now is. An
example would help I think.
Some questions:
- Does this mean we're going to change <feature> to not directly define
bridge mappings?
- Is the idea to have a new tag within <feature> that defines the bridge
binding?
- If not:
- what are we doing with plugins that define multiple <feature> tags?
- what are we doing if apps directly define <feature> tags directly in
their config.xml (outside of plugins)? This is still common for plugins
that haven't been updated to plugman. I think we do this for plugins
bundled with the platforms (e.g. Android's App plugin)
>
> Cons:
> - Harder to implement for us. "Should still take less time than
> arguing on the topic" said Braden ;-)
> - Previous Cordova platforms might or might not choke when they see
> JS-only plugins listed as <feature>s but it's unlikely.
>
Android chokes:
https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
Not sure if this was considered, but instead of using a config file, we
could generate a source file that gets compiled in. Would eliminate any
performance concerns and stay out of files that users might be peering at.
>
>
> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> <br...@chromium.org> wrote:
> > Following up on my big config-and-metadata summary in the other thread,
> the
> > file in question here is the platform config.xml (that is,
> > $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> > Significantly, this file is written by Plugman and CLI, and read by the
> > native platform. The user never reads or writes this file directly in the
> > normal flow of things.
> >
> > Braden
> >
> >
> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
> >
> >> There's a bit of a BC issue here because cordova.js needs to know what
> >> file to inject a <script> tag for, so it can load the file and then load
> >> its module. That's why I hesitated to modify the format of that file,
> >> originally. (It currently sets module.exports to an array of <js-module>
> >> info.) Like Andrew says, entirely possible to make the change, just that
> >> some care is required.
> >>
> >> Braden
> >>
> >>
> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> >> jbondc@gdesolutions.com> wrote:
> >>
> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> >>> > I'm going to attempt to summarize in point form:
> >>> >
> >>> > Goal:
> >>> > - Make available the list of installed plugins and their versions to
> >>> native side & JS
> >>> > side.
> >>> > - Needed by App Harness to know whether an app is compatible with
> its
> >>> > bundled set of plugins.
> >>> >
> >>> > Using cordova_plugins.js:
> >>> > - It doesn't have the information that we need
> >>> > - We could add the extra information, but not easily since the file
> >>> exports an
> >>> > array instead of an object.
> >>> > - This file is not currently parsed by the native layer, so having
> the
> >>> info here
> >>> > would be an extra IO on start-up.
> >>> >
> >>>
> >>> Great summary :)
> >>>
> >>> Is it difficult to rename ' cordova_plugins.js' to something more broad
> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
> >>> object?
> >>> Since it's generated code, first impression is there's no BC issue
> other
> >>> than doing another prepare.
> >>>
> >>> Doesn't seem like there's a way to avoid the extra IO on the native
> side
> >>> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
> >>> xml, how will the JS side access it?
> >>>
> >>> Broader problem is there's no single cordova meta file that's shared
> >>> between native & js. Considering that on some platforms, there's only
> >>> JavaScript, putting the information in JSON seems like a good move.
> >>>
> >>>
> >>
>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
So...
We just had a good chat about this topic with Braden and Gorkem and we
think that adding <param>s to the existing <feature> tag is better
than introducing a new one.
Pros:
- No new tags, less confusion.
- A good path towards having a unique top-level config.xml since we
can now identify which plugins are installed from the feature tag.
Therefore, we can better handle uninstalls and user edits to the file.
Cons:
- Harder to implement for us. "Should still take less time than
arguing on the topic" said Braden ;-)
- Previous Cordova platforms might or might not choke when they see
JS-only plugins listed as <feature>s but it's unlikely.
On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
<br...@chromium.org> wrote:
> Following up on my big config-and-metadata summary in the other thread, the
> file in question here is the platform config.xml (that is,
> $PROJECT/platforms/<platform>/.../config.xml, see my summary).
> Significantly, this file is written by Plugman and CLI, and read by the
> native platform. The user never reads or writes this file directly in the
> normal flow of things.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> There's a bit of a BC issue here because cordova.js needs to know what
>> file to inject a <script> tag for, so it can load the file and then load
>> its module. That's why I hesitated to modify the format of that file,
>> originally. (It currently sets module.exports to an array of <js-module>
>> info.) Like Andrew says, entirely possible to make the change, just that
>> some care is required.
>>
>> Braden
>>
>>
>> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
>> jbondc@gdesolutions.com> wrote:
>>
>>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
>>> > I'm going to attempt to summarize in point form:
>>> >
>>> > Goal:
>>> > - Make available the list of installed plugins and their versions to
>>> native side & JS
>>> > side.
>>> > - Needed by App Harness to know whether an app is compatible with its
>>> > bundled set of plugins.
>>> >
>>> > Using cordova_plugins.js:
>>> > - It doesn't have the information that we need
>>> > - We could add the extra information, but not easily since the file
>>> exports an
>>> > array instead of an object.
>>> > - This file is not currently parsed by the native layer, so having the
>>> info here
>>> > would be an extra IO on start-up.
>>> >
>>>
>>> Great summary :)
>>>
>>> Is it difficult to rename ' cordova_plugins.js' to something more broad
>>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
>>> object?
>>> Since it's generated code, first impression is there's no BC issue other
>>> than doing another prepare.
>>>
>>> Doesn't seem like there's a way to avoid the extra IO on the native side
>>> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
>>> xml, how will the JS side access it?
>>>
>>> Broader problem is there's no single cordova meta file that's shared
>>> between native & js. Considering that on some platforms, there's only
>>> JavaScript, putting the information in JSON seems like a good move.
>>>
>>>
>>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
Following up on my big config-and-metadata summary in the other thread, the
file in question here is the platform config.xml (that is,
$PROJECT/platforms/<platform>/.../config.xml, see my summary).
Significantly, this file is written by Plugman and CLI, and read by the
native platform. The user never reads or writes this file directly in the
normal flow of things.
Braden
On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson <br...@chromium.org>wrote:
> There's a bit of a BC issue here because cordova.js needs to know what
> file to inject a <script> tag for, so it can load the file and then load
> its module. That's why I hesitated to modify the format of that file,
> originally. (It currently sets module.exports to an array of <js-module>
> info.) Like Andrew says, entirely possible to make the change, just that
> some care is required.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
>> > I'm going to attempt to summarize in point form:
>> >
>> > Goal:
>> > - Make available the list of installed plugins and their versions to
>> native side & JS
>> > side.
>> > - Needed by App Harness to know whether an app is compatible with its
>> > bundled set of plugins.
>> >
>> > Using cordova_plugins.js:
>> > - It doesn't have the information that we need
>> > - We could add the extra information, but not easily since the file
>> exports an
>> > array instead of an object.
>> > - This file is not currently parsed by the native layer, so having the
>> info here
>> > would be an extra IO on start-up.
>> >
>>
>> Great summary :)
>>
>> Is it difficult to rename ' cordova_plugins.js' to something more broad
>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
>> object?
>> Since it's generated code, first impression is there's no BC issue other
>> than doing another prepare.
>>
>> Doesn't seem like there's a way to avoid the extra IO on the native side
>> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
>> xml, how will the JS side access it?
>>
>> Broader problem is there's no single cordova meta file that's shared
>> between native & js. Considering that on some platforms, there's only
>> JavaScript, putting the information in JSON seems like a good move.
>>
>>
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
There's a bit of a BC issue here because cordova.js needs to know what file
to inject a <script> tag for, so it can load the file and then load its
module. That's why I hesitated to modify the format of that file,
originally. (It currently sets module.exports to an array of <js-module>
info.) Like Andrew says, entirely possible to make the change, just that
some care is required.
Braden
On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> > I'm going to attempt to summarize in point form:
> >
> > Goal:
> > - Make available the list of installed plugins and their versions to
> native side & JS
> > side.
> > - Needed by App Harness to know whether an app is compatible with its
> > bundled set of plugins.
> >
> > Using cordova_plugins.js:
> > - It doesn't have the information that we need
> > - We could add the extra information, but not easily since the file
> exports an
> > array instead of an object.
> > - This file is not currently parsed by the native layer, so having the
> info here
> > would be an extra IO on start-up.
> >
>
> Great summary :)
>
> Is it difficult to rename ' cordova_plugins.js' to something more broad
> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an
> object?
> Since it's generated code, first impression is there's no BC issue other
> than doing another prepare.
>
> Doesn't seem like there's a way to avoid the extra IO on the native side
> (e.g. cordova_meta.js). If the detailed list of installed plugins is in
> xml, how will the JS side access it?
>
> Broader problem is there's no single cordova meta file that's shared
> between native & js. Considering that on some platforms, there's only
> JavaScript, putting the information in JSON seems like a good move.
>
>
RE: tag, and accessing the plugin list
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> I'm going to attempt to summarize in point form:
>
> Goal:
> - Make available the list of installed plugins and their versions to native side & JS
> side.
> - Needed by App Harness to know whether an app is compatible with its
> bundled set of plugins.
>
> Using cordova_plugins.js:
> - It doesn't have the information that we need
> - We could add the extra information, but not easily since the file exports an
> array instead of an object.
> - This file is not currently parsed by the native layer, so having the info here
> would be an extra IO on start-up.
>
Great summary :)
Is it difficult to rename ' cordova_plugins.js' to something more broad 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an object?
Since it's generated code, first impression is there's no BC issue other than doing another prepare.
Doesn't seem like there's a way to avoid the extra IO on the native side (e.g. cordova_meta.js). If the detailed list of installed plugins is in xml, how will the JS side access it?
Broader problem is there's no single cordova meta file that's shared between native & js. Considering that on some platforms, there's only JavaScript, putting the information in JSON seems like a good move.
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
Alright. How about 4:30 PM EST UTC-5 ? Whomever is interested can join
up to the 10 participants limit.
On Thu, Nov 14, 2013 at 11:25 AM, Braden Shepherdson
<br...@chromium.org> wrote:
> I'm definitely willing to jump on a Hangout this afternoon. Anytime from
> now through about three hours from now works for me.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 2:19 PM, Anis KADRI <an...@gmail.com> wrote:
>
>> Let's google hangout about this and report back to the list yeah ?
>>
>> My main concern is user confusion like here [1]. When a plugin fails
>> to load/work, people start looking around config files and wonder why
>> it's broken and I feel like the more config stuff we add the more
>> confusion it creates.
>>
>> [1] https://github.com/imhotep/MapKit/issues/18#issuecomment-25952856
>>
>> On Thu, Nov 14, 2013 at 10:53 AM, Braden Shepherdson
>> <br...@chromium.org> wrote:
>> > I apologize for getting somewhat short in my previous email.
>> >
>> > Let me explain my comment on needing "more, and more hacky, code".
>> Because
>> > of how Plugman parses the <config-file> tags and makes the edits to the
>> XML
>> > files, it would require special-case logic to find <feature> tags and
>> > inject this extra information into them. Only some <config-file> tags are
>> > pointing at the right file and XPath, and this would have Plugman
>> examining
>> > the children of <config-file> tags instead of treating it as a black box
>> > and copying it in. My proposal of injecting new tags doesn't require
>> > anything like that, Plugman just adds an extra config-munge entry for
>> each
>> > plugin, after it's finished parsing the <config-file> tags. The patch to
>> > implement this only added a few lines.
>> >
>> > This information is being injected by Plugman into the platform
>> config.xml
>> > (the build artifact) at plugman-prepare time. It isn't visible directly
>> to
>> > plugin devs, app devs, or users. But it allows an app or plugin dev who
>> > wants to know what plugins are installed to find out. This allows
>> checking
>> > for an optional dependency, and lets AppHarness check compatibility of
>> its
>> > own plugins with those required by a child app.
>> >
>> > Braden
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Nov 14, 2013 at 1:44 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>> >
>> >> I'm going to attempt to summarize in point form:
>> >>
>> >> Goal:
>> >> - Make available the list of installed plugins and their versions to
>> >> native side & JS side.
>> >> - Needed by App Harness to know whether an app is compatible with its
>> >> bundled set of plugins.
>> >>
>> >> Using cordova_plugins.js:
>> >> - It doesn't have the information that we need
>> >> - We could add the extra information, but not easily since the file
>> >> exports an array instead of an object.
>> >> - This file is not currently parsed by the native layer, so having the
>> >> info here would be an extra IO on start-up.
>> >>
>> >> Using config.xml:
>> >> - It doesn't have the information that we need
>> >> - This is always loaded by native sides, so it's a nice fit.
>> >>
>> >> Using <feature>:
>> >> - These are for defining Bridge channels
>> >> - Plugins define 0 or more of these
>> >> - Adding empty ones for plugins that don't define them causes
>> exceptions
>> >> in the native layer. We'd like this change to not break older versions
>> of
>> >> cordova.
>> >>
>> >> So, although it seems like <feature> would make sense, we've already
>> used
>> >> <feature> to mean something else (bridge channels).
>> >>
>> >> I think Braden's suggestion of adding a new tag is the simplest, both
>> >> implementation-wise, as well as semantically (it has a single,
>> well-defined
>> >> purpose). What I especially like about it, is that it separates which
>> tags
>> >> are written by plugin devs (<feature>) from tags that are generated by
>> >> plugman (<cordova-plugin>)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
>> >>
>> >> > Ok, everybody be calm. We are adults and we are capable of working
>> >> through
>> >> > this in a dispassionate manner and has nothing to do with you, your
>> code,
>> >> > or whatever. We all just want to find the best solution. Blankets
>> >> > statements like 'more hacky code' does no good. Let's just stick to
>> >> factual
>> >> > stuff and stay away from subjective identification. Ok?
>> >> >
>> >> > "as to leaking into userland, these <feature> tags are relevant to
>> plugin
>> >> > developers" ... so would this particular information belong to
>> >> > plugin.xml????
>> >> >
>> >> > Also, Joe had a good question earlier. Despite all this problem
>> solving I
>> >> > have no idea what the actual problem is we are trying to solve. We
>> have
>> >> > lots of solutions but what precisely do our users gain from runtime
>> >> > introspection here?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
>> >> braden@chromium.org
>> >> > >wrote:
>> >> >
>> >> > > Brian, as to leaking into userland, these <feature> tags are
>> relevant
>> >> to
>> >> > > plugin developers, since they have to define the mapping of exec
>> names
>> >> to
>> >> > > native files so we can load their plugins. None of this is visible
>> to
>> >> app
>> >> > > developers or end users.
>> >> > >
>> >> > > We're not paying by the byte, or the top-level tag, in config.xml.
>> NB
>> >> > that
>> >> > > this is the platform config.xml, the one that's a build artifact no
>> one
>> >> > but
>> >> > > the platform code is ever supposed to look at. Why are we sweating
>> so
>> >> > hard
>> >> > > over adding some new information into the file, and trying to
>> shoehorn
>> >> it
>> >> > > into existing tags? The code to handle this is simpler in Plugman
>> and
>> >> on
>> >> > > the platforms to have this be a separate tag, rather than mixing it
>> in
>> >> > with
>> >> > > <feature>.
>> >> > >
>> >> > > If we want to use <feature> tags for this, despite it requiring
>> more,
>> >> and
>> >> > > more hacky, code all around, we're going to need a good reason. I
>> >> haven't
>> >> > > heard any reason for why using <feature> gains us anything.
>> >> > >
>> >> > > Carlos, as I noted in my remixed proposal above, I originally
>> wanted to
>> >> > use
>> >> > > cordova_plugins.js or a similar www/ file for this, but there are
>> >> > problems
>> >> > > with that. On the other hand, I would much rather add a new file
>> that
>> >> can
>> >> > > be loaded as a js-module than do this using hacked-up <feature>
>> tags.
>> >> > >
>> >> > > Braden
>> >> > >
>> >> > >
>> >> > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <
>> don.coleman@gmail.com>
>> >> > > wrote:
>> >> > >
>> >> > > > 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 <bo...@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 <sh...@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
>> >> > > > > >> > > > > > ><br...@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
>> >> > > > > >> > > > > > >> > > > > > > >
>> >> > > > > >> > > > > > >> > > > > > >
>> >> > > > > >> > > > > > >> > > > > >
>> >> > > > > >> > > > > > >> > > > >
>> >> > > > > >> > > > > > >> > > >
>> >> > > > > >> > > > > > >> > >
>> >> > > > > >> > > > > > >> >
>> >> > > > > >> > > > > > >>
>> >> > > > > >> > > > > >
>> >> > > > > >> > > > > >
>> >> > > > > >> > > > >
>> >> > > > > >> > > >
>> >> > > > > >> > >
>> >> > > > > >> >
>> >> > > > > >>
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
I'm definitely willing to jump on a Hangout this afternoon. Anytime from
now through about three hours from now works for me.
Braden
On Thu, Nov 14, 2013 at 2:19 PM, Anis KADRI <an...@gmail.com> wrote:
> Let's google hangout about this and report back to the list yeah ?
>
> My main concern is user confusion like here [1]. When a plugin fails
> to load/work, people start looking around config files and wonder why
> it's broken and I feel like the more config stuff we add the more
> confusion it creates.
>
> [1] https://github.com/imhotep/MapKit/issues/18#issuecomment-25952856
>
> On Thu, Nov 14, 2013 at 10:53 AM, Braden Shepherdson
> <br...@chromium.org> wrote:
> > I apologize for getting somewhat short in my previous email.
> >
> > Let me explain my comment on needing "more, and more hacky, code".
> Because
> > of how Plugman parses the <config-file> tags and makes the edits to the
> XML
> > files, it would require special-case logic to find <feature> tags and
> > inject this extra information into them. Only some <config-file> tags are
> > pointing at the right file and XPath, and this would have Plugman
> examining
> > the children of <config-file> tags instead of treating it as a black box
> > and copying it in. My proposal of injecting new tags doesn't require
> > anything like that, Plugman just adds an extra config-munge entry for
> each
> > plugin, after it's finished parsing the <config-file> tags. The patch to
> > implement this only added a few lines.
> >
> > This information is being injected by Plugman into the platform
> config.xml
> > (the build artifact) at plugman-prepare time. It isn't visible directly
> to
> > plugin devs, app devs, or users. But it allows an app or plugin dev who
> > wants to know what plugins are installed to find out. This allows
> checking
> > for an optional dependency, and lets AppHarness check compatibility of
> its
> > own plugins with those required by a child app.
> >
> > Braden
> >
> >
> >
> >
> >
> > On Thu, Nov 14, 2013 at 1:44 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >
> >> I'm going to attempt to summarize in point form:
> >>
> >> Goal:
> >> - Make available the list of installed plugins and their versions to
> >> native side & JS side.
> >> - Needed by App Harness to know whether an app is compatible with its
> >> bundled set of plugins.
> >>
> >> Using cordova_plugins.js:
> >> - It doesn't have the information that we need
> >> - We could add the extra information, but not easily since the file
> >> exports an array instead of an object.
> >> - This file is not currently parsed by the native layer, so having the
> >> info here would be an extra IO on start-up.
> >>
> >> Using config.xml:
> >> - It doesn't have the information that we need
> >> - This is always loaded by native sides, so it's a nice fit.
> >>
> >> Using <feature>:
> >> - These are for defining Bridge channels
> >> - Plugins define 0 or more of these
> >> - Adding empty ones for plugins that don't define them causes
> exceptions
> >> in the native layer. We'd like this change to not break older versions
> of
> >> cordova.
> >>
> >> So, although it seems like <feature> would make sense, we've already
> used
> >> <feature> to mean something else (bridge channels).
> >>
> >> I think Braden's suggestion of adding a new tag is the simplest, both
> >> implementation-wise, as well as semantically (it has a single,
> well-defined
> >> purpose). What I especially like about it, is that it separates which
> tags
> >> are written by plugin devs (<feature>) from tags that are generated by
> >> plugman (<cordova-plugin>)
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >> > Ok, everybody be calm. We are adults and we are capable of working
> >> through
> >> > this in a dispassionate manner and has nothing to do with you, your
> code,
> >> > or whatever. We all just want to find the best solution. Blankets
> >> > statements like 'more hacky code' does no good. Let's just stick to
> >> factual
> >> > stuff and stay away from subjective identification. Ok?
> >> >
> >> > "as to leaking into userland, these <feature> tags are relevant to
> plugin
> >> > developers" ... so would this particular information belong to
> >> > plugin.xml????
> >> >
> >> > Also, Joe had a good question earlier. Despite all this problem
> solving I
> >> > have no idea what the actual problem is we are trying to solve. We
> have
> >> > lots of solutions but what precisely do our users gain from runtime
> >> > introspection here?
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
> >> braden@chromium.org
> >> > >wrote:
> >> >
> >> > > Brian, as to leaking into userland, these <feature> tags are
> relevant
> >> to
> >> > > plugin developers, since they have to define the mapping of exec
> names
> >> to
> >> > > native files so we can load their plugins. None of this is visible
> to
> >> app
> >> > > developers or end users.
> >> > >
> >> > > We're not paying by the byte, or the top-level tag, in config.xml.
> NB
> >> > that
> >> > > this is the platform config.xml, the one that's a build artifact no
> one
> >> > but
> >> > > the platform code is ever supposed to look at. Why are we sweating
> so
> >> > hard
> >> > > over adding some new information into the file, and trying to
> shoehorn
> >> it
> >> > > into existing tags? The code to handle this is simpler in Plugman
> and
> >> on
> >> > > the platforms to have this be a separate tag, rather than mixing it
> in
> >> > with
> >> > > <feature>.
> >> > >
> >> > > If we want to use <feature> tags for this, despite it requiring
> more,
> >> and
> >> > > more hacky, code all around, we're going to need a good reason. I
> >> haven't
> >> > > heard any reason for why using <feature> gains us anything.
> >> > >
> >> > > Carlos, as I noted in my remixed proposal above, I originally
> wanted to
> >> > use
> >> > > cordova_plugins.js or a similar www/ file for this, but there are
> >> > problems
> >> > > with that. On the other hand, I would much rather add a new file
> that
> >> can
> >> > > be loaded as a js-module than do this using hacked-up <feature>
> tags.
> >> > >
> >> > > Braden
> >> > >
> >> > >
> >> > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <
> don.coleman@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > 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 <bo...@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 <sh...@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
> >> > > > > >> > > > > > ><br...@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
> >> > > > > >> > > > > > >> > > > > > > >
> >> > > > > >> > > > > > >> > > > > > >
> >> > > > > >> > > > > > >> > > > > >
> >> > > > > >> > > > > > >> > > > >
> >> > > > > >> > > > > > >> > > >
> >> > > > > >> > > > > > >> > >
> >> > > > > >> > > > > > >> >
> >> > > > > >> > > > > > >>
> >> > > > > >> > > > > >
> >> > > > > >> > > > > >
> >> > > > > >> > > > >
> >> > > > > >> > > >
> >> > > > > >> > >
> >> > > > > >> >
> >> > > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
Let's google hangout about this and report back to the list yeah ?
My main concern is user confusion like here [1]. When a plugin fails
to load/work, people start looking around config files and wonder why
it's broken and I feel like the more config stuff we add the more
confusion it creates.
[1] https://github.com/imhotep/MapKit/issues/18#issuecomment-25952856
On Thu, Nov 14, 2013 at 10:53 AM, Braden Shepherdson
<br...@chromium.org> wrote:
> I apologize for getting somewhat short in my previous email.
>
> Let me explain my comment on needing "more, and more hacky, code". Because
> of how Plugman parses the <config-file> tags and makes the edits to the XML
> files, it would require special-case logic to find <feature> tags and
> inject this extra information into them. Only some <config-file> tags are
> pointing at the right file and XPath, and this would have Plugman examining
> the children of <config-file> tags instead of treating it as a black box
> and copying it in. My proposal of injecting new tags doesn't require
> anything like that, Plugman just adds an extra config-munge entry for each
> plugin, after it's finished parsing the <config-file> tags. The patch to
> implement this only added a few lines.
>
> This information is being injected by Plugman into the platform config.xml
> (the build artifact) at plugman-prepare time. It isn't visible directly to
> plugin devs, app devs, or users. But it allows an app or plugin dev who
> wants to know what plugins are installed to find out. This allows checking
> for an optional dependency, and lets AppHarness check compatibility of its
> own plugins with those required by a child app.
>
> Braden
>
>
>
>
>
> On Thu, Nov 14, 2013 at 1:44 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>> I'm going to attempt to summarize in point form:
>>
>> Goal:
>> - Make available the list of installed plugins and their versions to
>> native side & JS side.
>> - Needed by App Harness to know whether an app is compatible with its
>> bundled set of plugins.
>>
>> Using cordova_plugins.js:
>> - It doesn't have the information that we need
>> - We could add the extra information, but not easily since the file
>> exports an array instead of an object.
>> - This file is not currently parsed by the native layer, so having the
>> info here would be an extra IO on start-up.
>>
>> Using config.xml:
>> - It doesn't have the information that we need
>> - This is always loaded by native sides, so it's a nice fit.
>>
>> Using <feature>:
>> - These are for defining Bridge channels
>> - Plugins define 0 or more of these
>> - Adding empty ones for plugins that don't define them causes exceptions
>> in the native layer. We'd like this change to not break older versions of
>> cordova.
>>
>> So, although it seems like <feature> would make sense, we've already used
>> <feature> to mean something else (bridge channels).
>>
>> I think Braden's suggestion of adding a new tag is the simplest, both
>> implementation-wise, as well as semantically (it has a single, well-defined
>> purpose). What I especially like about it, is that it separates which tags
>> are written by plugin devs (<feature>) from tags that are generated by
>> plugman (<cordova-plugin>)
>>
>>
>>
>>
>>
>> On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > Ok, everybody be calm. We are adults and we are capable of working
>> through
>> > this in a dispassionate manner and has nothing to do with you, your code,
>> > or whatever. We all just want to find the best solution. Blankets
>> > statements like 'more hacky code' does no good. Let's just stick to
>> factual
>> > stuff and stay away from subjective identification. Ok?
>> >
>> > "as to leaking into userland, these <feature> tags are relevant to plugin
>> > developers" ... so would this particular information belong to
>> > plugin.xml????
>> >
>> > Also, Joe had a good question earlier. Despite all this problem solving I
>> > have no idea what the actual problem is we are trying to solve. We have
>> > lots of solutions but what precisely do our users gain from runtime
>> > introspection here?
>> >
>> >
>> >
>> >
>> > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
>> braden@chromium.org
>> > >wrote:
>> >
>> > > Brian, as to leaking into userland, these <feature> tags are relevant
>> to
>> > > plugin developers, since they have to define the mapping of exec names
>> to
>> > > native files so we can load their plugins. None of this is visible to
>> app
>> > > developers or end users.
>> > >
>> > > We're not paying by the byte, or the top-level tag, in config.xml. NB
>> > that
>> > > this is the platform config.xml, the one that's a build artifact no one
>> > but
>> > > the platform code is ever supposed to look at. Why are we sweating so
>> > hard
>> > > over adding some new information into the file, and trying to shoehorn
>> it
>> > > into existing tags? The code to handle this is simpler in Plugman and
>> on
>> > > the platforms to have this be a separate tag, rather than mixing it in
>> > with
>> > > <feature>.
>> > >
>> > > If we want to use <feature> tags for this, despite it requiring more,
>> and
>> > > more hacky, code all around, we're going to need a good reason. I
>> haven't
>> > > heard any reason for why using <feature> gains us anything.
>> > >
>> > > Carlos, as I noted in my remixed proposal above, I originally wanted to
>> > use
>> > > cordova_plugins.js or a similar www/ file for this, but there are
>> > problems
>> > > with that. On the other hand, I would much rather add a new file that
>> can
>> > > be loaded as a js-module than do this using hacked-up <feature> tags.
>> > >
>> > > Braden
>> > >
>> > >
>> > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <do...@gmail.com>
>> > > wrote:
>> > >
>> > > > 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 <bo...@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 <sh...@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
>> > > > > >> > > > > > ><br...@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
>> > > > > >> > > > > > >> > > > > > > >
>> > > > > >> > > > > > >> > > > > > >
>> > > > > >> > > > > > >> > > > > >
>> > > > > >> > > > > > >> > > > >
>> > > > > >> > > > > > >> > > >
>> > > > > >> > > > > > >> > >
>> > > > > >> > > > > > >> >
>> > > > > >> > > > > > >>
>> > > > > >> > > > > >
>> > > > > >> > > > > >
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
I apologize for getting somewhat short in my previous email.
Let me explain my comment on needing "more, and more hacky, code". Because
of how Plugman parses the <config-file> tags and makes the edits to the XML
files, it would require special-case logic to find <feature> tags and
inject this extra information into them. Only some <config-file> tags are
pointing at the right file and XPath, and this would have Plugman examining
the children of <config-file> tags instead of treating it as a black box
and copying it in. My proposal of injecting new tags doesn't require
anything like that, Plugman just adds an extra config-munge entry for each
plugin, after it's finished parsing the <config-file> tags. The patch to
implement this only added a few lines.
This information is being injected by Plugman into the platform config.xml
(the build artifact) at plugman-prepare time. It isn't visible directly to
plugin devs, app devs, or users. But it allows an app or plugin dev who
wants to know what plugins are installed to find out. This allows checking
for an optional dependency, and lets AppHarness check compatibility of its
own plugins with those required by a child app.
Braden
On Thu, Nov 14, 2013 at 1:44 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I'm going to attempt to summarize in point form:
>
> Goal:
> - Make available the list of installed plugins and their versions to
> native side & JS side.
> - Needed by App Harness to know whether an app is compatible with its
> bundled set of plugins.
>
> Using cordova_plugins.js:
> - It doesn't have the information that we need
> - We could add the extra information, but not easily since the file
> exports an array instead of an object.
> - This file is not currently parsed by the native layer, so having the
> info here would be an extra IO on start-up.
>
> Using config.xml:
> - It doesn't have the information that we need
> - This is always loaded by native sides, so it's a nice fit.
>
> Using <feature>:
> - These are for defining Bridge channels
> - Plugins define 0 or more of these
> - Adding empty ones for plugins that don't define them causes exceptions
> in the native layer. We'd like this change to not break older versions of
> cordova.
>
> So, although it seems like <feature> would make sense, we've already used
> <feature> to mean something else (bridge channels).
>
> I think Braden's suggestion of adding a new tag is the simplest, both
> implementation-wise, as well as semantically (it has a single, well-defined
> purpose). What I especially like about it, is that it separates which tags
> are written by plugin devs (<feature>) from tags that are generated by
> plugman (<cordova-plugin>)
>
>
>
>
>
> On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Ok, everybody be calm. We are adults and we are capable of working
> through
> > this in a dispassionate manner and has nothing to do with you, your code,
> > or whatever. We all just want to find the best solution. Blankets
> > statements like 'more hacky code' does no good. Let's just stick to
> factual
> > stuff and stay away from subjective identification. Ok?
> >
> > "as to leaking into userland, these <feature> tags are relevant to plugin
> > developers" ... so would this particular information belong to
> > plugin.xml????
> >
> > Also, Joe had a good question earlier. Despite all this problem solving I
> > have no idea what the actual problem is we are trying to solve. We have
> > lots of solutions but what precisely do our users gain from runtime
> > introspection here?
> >
> >
> >
> >
> > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
> braden@chromium.org
> > >wrote:
> >
> > > Brian, as to leaking into userland, these <feature> tags are relevant
> to
> > > plugin developers, since they have to define the mapping of exec names
> to
> > > native files so we can load their plugins. None of this is visible to
> app
> > > developers or end users.
> > >
> > > We're not paying by the byte, or the top-level tag, in config.xml. NB
> > that
> > > this is the platform config.xml, the one that's a build artifact no one
> > but
> > > the platform code is ever supposed to look at. Why are we sweating so
> > hard
> > > over adding some new information into the file, and trying to shoehorn
> it
> > > into existing tags? The code to handle this is simpler in Plugman and
> on
> > > the platforms to have this be a separate tag, rather than mixing it in
> > with
> > > <feature>.
> > >
> > > If we want to use <feature> tags for this, despite it requiring more,
> and
> > > more hacky, code all around, we're going to need a good reason. I
> haven't
> > > heard any reason for why using <feature> gains us anything.
> > >
> > > Carlos, as I noted in my remixed proposal above, I originally wanted to
> > use
> > > cordova_plugins.js or a similar www/ file for this, but there are
> > problems
> > > with that. On the other hand, I would much rather add a new file that
> can
> > > be loaded as a js-module than do this using hacked-up <feature> tags.
> > >
> > > Braden
> > >
> > >
> > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <do...@gmail.com>
> > > wrote:
> > >
> > > > 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 <bo...@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 <sh...@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
> > > > > >> > > > > > ><br...@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
> > > > > >> > > > > > >> > > > > > > >
> > > > > >> > > > > > >> > > > > > >
> > > > > >> > > > > > >> > > > > >
> > > > > >> > > > > > >> > > > >
> > > > > >> > > > > > >> > > >
> > > > > >> > > > > > >> > >
> > > > > >> > > > > > >> >
> > > > > >> > > > > > >>
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Andrew Grieve <ag...@chromium.org>.
I'm going to attempt to summarize in point form:
Goal:
- Make available the list of installed plugins and their versions to
native side & JS side.
- Needed by App Harness to know whether an app is compatible with its
bundled set of plugins.
Using cordova_plugins.js:
- It doesn't have the information that we need
- We could add the extra information, but not easily since the file
exports an array instead of an object.
- This file is not currently parsed by the native layer, so having the
info here would be an extra IO on start-up.
Using config.xml:
- It doesn't have the information that we need
- This is always loaded by native sides, so it's a nice fit.
Using <feature>:
- These are for defining Bridge channels
- Plugins define 0 or more of these
- Adding empty ones for plugins that don't define them causes exceptions
in the native layer. We'd like this change to not break older versions of
cordova.
So, although it seems like <feature> would make sense, we've already used
<feature> to mean something else (bridge channels).
I think Braden's suggestion of adding a new tag is the simplest, both
implementation-wise, as well as semantically (it has a single, well-defined
purpose). What I especially like about it, is that it separates which tags
are written by plugin devs (<feature>) from tags that are generated by
plugman (<cordova-plugin>)
On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote:
> Ok, everybody be calm. We are adults and we are capable of working through
> this in a dispassionate manner and has nothing to do with you, your code,
> or whatever. We all just want to find the best solution. Blankets
> statements like 'more hacky code' does no good. Let's just stick to factual
> stuff and stay away from subjective identification. Ok?
>
> "as to leaking into userland, these <feature> tags are relevant to plugin
> developers" ... so would this particular information belong to
> plugin.xml????
>
> Also, Joe had a good question earlier. Despite all this problem solving I
> have no idea what the actual problem is we are trying to solve. We have
> lots of solutions but what precisely do our users gain from runtime
> introspection here?
>
>
>
>
> On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Brian, as to leaking into userland, these <feature> tags are relevant to
> > plugin developers, since they have to define the mapping of exec names to
> > native files so we can load their plugins. None of this is visible to app
> > developers or end users.
> >
> > We're not paying by the byte, or the top-level tag, in config.xml. NB
> that
> > this is the platform config.xml, the one that's a build artifact no one
> but
> > the platform code is ever supposed to look at. Why are we sweating so
> hard
> > over adding some new information into the file, and trying to shoehorn it
> > into existing tags? The code to handle this is simpler in Plugman and on
> > the platforms to have this be a separate tag, rather than mixing it in
> with
> > <feature>.
> >
> > If we want to use <feature> tags for this, despite it requiring more, and
> > more hacky, code all around, we're going to need a good reason. I haven't
> > heard any reason for why using <feature> gains us anything.
> >
> > Carlos, as I noted in my remixed proposal above, I originally wanted to
> use
> > cordova_plugins.js or a similar www/ file for this, but there are
> problems
> > with that. On the other hand, I would much rather add a new file that can
> > be loaded as a js-module than do this using hacked-up <feature> tags.
> >
> > Braden
> >
> >
> > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <do...@gmail.com>
> > wrote:
> >
> > > 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 <bo...@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 <sh...@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 <sh...@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
> > > > >> > > > > > ><br...@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
> > > > >> > > > > > >> > > > > > > >
> > > > >> > > > > > >> > > > > > >
> > > > >> > > > > > >> > > > > >
> > > > >> > > > > > >> > > > >
> > > > >> > > > > > >> > > >
> > > > >> > > > > > >> > >
> > > > >> > > > > > >> >
> > > > >> > > > > > >>
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
Ok, everybody be calm. We are adults and we are capable of working through
this in a dispassionate manner and has nothing to do with you, your code,
or whatever. We all just want to find the best solution. Blankets
statements like 'more hacky code' does no good. Let's just stick to factual
stuff and stay away from subjective identification. Ok?
"as to leaking into userland, these <feature> tags are relevant to plugin
developers" ... so would this particular information belong to
plugin.xml????
Also, Joe had a good question earlier. Despite all this problem solving I
have no idea what the actual problem is we are trying to solve. We have
lots of solutions but what precisely do our users gain from runtime
introspection here?
On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <br...@chromium.org>wrote:
> Brian, as to leaking into userland, these <feature> tags are relevant to
> plugin developers, since they have to define the mapping of exec names to
> native files so we can load their plugins. None of this is visible to app
> developers or end users.
>
> We're not paying by the byte, or the top-level tag, in config.xml. NB that
> this is the platform config.xml, the one that's a build artifact no one but
> the platform code is ever supposed to look at. Why are we sweating so hard
> over adding some new information into the file, and trying to shoehorn it
> into existing tags? The code to handle this is simpler in Plugman and on
> the platforms to have this be a separate tag, rather than mixing it in with
> <feature>.
>
> If we want to use <feature> tags for this, despite it requiring more, and
> more hacky, code all around, we're going to need a good reason. I haven't
> heard any reason for why using <feature> gains us anything.
>
> Carlos, as I noted in my remixed proposal above, I originally wanted to use
> cordova_plugins.js or a similar www/ file for this, but there are problems
> with that. On the other hand, I would much rather add a new file that can
> be loaded as a js-module than do this using hacked-up <feature> tags.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <do...@gmail.com>
> wrote:
>
> > 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 <bo...@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 <sh...@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 <pu...@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 <sh...@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
> > > >> > > > > > ><br...@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
> > > >> > > > > > >> > > > > > > >
> > > >> > > > > > >> > > > > > >
> > > >> > > > > > >> > > > > >
> > > >> > > > > > >> > > > >
> > > >> > > > > > >> > > >
> > > >> > > > > > >> > >
> > > >> > > > > > >> >
> > > >> > > > > > >>
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
Brian, as to leaking into userland, these <feature> tags are relevant to
plugin developers, since they have to define the mapping of exec names to
native files so we can load their plugins. None of this is visible to app
developers or end users.
We're not paying by the byte, or the top-level tag, in config.xml. NB that
this is the platform config.xml, the one that's a build artifact no one but
the platform code is ever supposed to look at. Why are we sweating so hard
over adding some new information into the file, and trying to shoehorn it
into existing tags? The code to handle this is simpler in Plugman and on
the platforms to have this be a separate tag, rather than mixing it in with
<feature>.
If we want to use <feature> tags for this, despite it requiring more, and
more hacky, code all around, we're going to need a good reason. I haven't
heard any reason for why using <feature> gains us anything.
Carlos, as I noted in my remixed proposal above, I originally wanted to use
cordova_plugins.js or a similar www/ file for this, but there are problems
with that. On the other hand, I would much rather add a new file that can
be loaded as a js-module than do this using hacked-up <feature> tags.
Braden
On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <do...@gmail.com> wrote:
> 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 <bo...@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 <sh...@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 <pu...@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 <sh...@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
> > >> > > > > > ><br...@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
> > >> > > > > > >> > > > > > > >
> > >> > > > > > >> > > > > > >
> > >> > > > > > >> > > > > >
> > >> > > > > > >> > > > >
> > >> > > > > > >> > > >
> > >> > > > > > >> > >
> > >> > > > > > >> >
> > >> > > > > > >>
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
Re: tag, and accessing the plugin list
Posted by Don Coleman <do...@gmail.com>.
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 <bo...@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 <sh...@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 <pu...@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 <sh...@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
> >> > > > > > ><br...@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
> >> > > > > > >> > > > > > > >
> >> > > > > > >> > > > > > >
> >> > > > > > >> > > > > >
> >> > > > > > >> > > > >
> >> > > > > > >> > > >
> >> > > > > > >> > >
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re: tag, and accessing the plugin list
Posted by Carlos Santana <cs...@gmail.com>.
Why not use plugins/*.json or www/cordova_plugins.js to stored the
installed plugins instead of putting that info in config.xml?
If the information is present in a .json file in www/ then all platform
benefit and can read this info from web runtime, if the native needs the
information then use the bridge and send the information from javascript to
native.
For example the implementation will be much more simpler "cp
plugins/[platform].json platforms/[platform]/www/cordova_plugins.json
Installed plugins might be useful information to a user building a cordova
apps or supporting them it will be useful to have this info when diagnosing
problems.
my 2 cents, and maybe I don't get the point.
On Thu, Nov 14, 2013 at 12:33 PM, Michal Mocny <mm...@chromium.org> wrote:
> Yes, there are valid js-module-only plugins. Some reasons why it is useful
> to have them bundled as cordova plugins even if they could have been
> shipped as js libraries, is that (a) they can be set as plugin dependencies
> with support for de-duplication,, (b) some plugins have native code only on
> a subset of platforms, and (c) consistency for user workflow.
>
> A few quick examples are
> mobile-chrome-apps' polyfill-xhr-features, polyfill-blob-constructor,
> and polyfill-CustomEvent, but its very likely there are others.
>
>
> On Thu, Nov 14, 2013 at 12:26 PM, Joe Bowser <bo...@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 <sh...@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 <pu...@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 <sh...@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
> > >> > > > > > ><br...@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
> > >> > > > > > >> > > > > > > >
> > >> > > > > > >> > > > > > >
> > >> > > > > > >> > > > > >
> > >> > > > > > >> > > > >
> > >> > > > > > >> > > >
> > >> > > > > > >> > >
> > >> > > > > > >> >
> > >> > > > > > >>
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: tag, and accessing the plugin list
Posted by Michal Mocny <mm...@chromium.org>.
Yes, there are valid js-module-only plugins. Some reasons why it is useful
to have them bundled as cordova plugins even if they could have been
shipped as js libraries, is that (a) they can be set as plugin dependencies
with support for de-duplication,, (b) some plugins have native code only on
a subset of platforms, and (c) consistency for user workflow.
A few quick examples are
mobile-chrome-apps' polyfill-xhr-features, polyfill-blob-constructor,
and polyfill-CustomEvent, but its very likely there are others.
On Thu, Nov 14, 2013 at 12:26 PM, Joe Bowser <bo...@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 <sh...@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 <pu...@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 <sh...@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
> >> > > > > > ><br...@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
> >> > > > > > >> > > > > > > >
> >> > > > > > >> > > > > > >
> >> > > > > > >> > > > > >
> >> > > > > > >> > > > >
> >> > > > > > >> > > >
> >> > > > > > >> > >
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re: tag, and accessing the plugin list
Posted by Joe Bowser <bo...@gmail.com>.
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 <br...@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 <sh...@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 <pu...@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 <sh...@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 <sh...@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
>> > > > > > ><br...@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
>> > > > > > >> > > > > > > >
>> > > > > > >> > > > > > >
>> > > > > > >> > > > > >
>> > > > > > >> > > > >
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
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?
On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson <br...@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 <sh...@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 <pu...@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 <sh...@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 <sh...@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
> > > > > > ><br...@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
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Joe Bowser <bo...@gmail.com>.
On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson <br...@chromium.org> wrote:
>
> 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.
>
I don't see why a change in an XML parser is a huge deal.
> 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 don't think we should add this plugin tag. This is just going to
cause even more confusion among our users. I don't think sacrifice
clarity for developer convenience.
> 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?
I think this should go in the feature tag so that it's clear what's
going on. How is this feature supposed to help our users?
> On Wed, Nov 13, 2013 at 7:25 PM, Shazron <sh...@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 <pu...@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 <sh...@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 <sh...@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
>> > > > > ><br...@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
>> > > > > >> > > > > > > >
>> > > > > >> > > > > > >
>> > > > > >> > > > > >
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
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 <sh...@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 <pu...@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 <sh...@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 <sh...@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
> > > > > ><br...@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
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Shazron <sh...@gmail.com>.
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 <pu...@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 <sh...@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 <sh...@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
> > > > ><br...@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" <go...@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
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Gorkem Ercan <go...@gmail.com>.
inlined
On Wed, Nov 13, 2013 at 6:43 PM, Jesse <pu...@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>
>
This was the original intention with this tag actually and It still seems
to work.
JBoss tools actually merges all feature tags into one during plugin
installation and at least on iOS and Android (with Cordova 3.1)
it works.
>
> 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
>
plugman can inject feature tags for them. I think runtimes will silently
ignore it.
> 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. )
>
Two different things here.
Changing names to ids forces plugins to single point of contract.
Otherwise having id as a param on the feature tag does not.
>
> 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 <sh...@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 <sh...@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
> > > > ><br...@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" <go...@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
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Jesse <pu...@gmail.com>.
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 <sh...@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 <sh...@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
> > > ><br...@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" <go...@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
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Shazron <sh...@gmail.com>.
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 <sh...@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
> > ><br...@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" <go...@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
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> >
>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
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 <sh...@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
>> ><br...@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" <go...@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
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
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 <sh...@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
> ><br...@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" <go...@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
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
Re: tag, and accessing the plugin list
Posted by Shazron Abdullah <sh...@adobe.com>.
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
><br...@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" <go...@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 <pu...@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
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
what are we using <feature> for?
On Wed, Nov 13, 2013 at 2:27 PM, Braden Shepherdson <br...@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" <go...@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 <pu...@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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@google.com>.
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" <go...@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 <pu...@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Brian LeRoux <b...@brian.io>.
here's a query: what are we using <feature> for?
On Wed, Nov 13, 2013 at 1:39 PM, Gorkem Ercan <go...@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 <pu...@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Gorkem Ercan <go...@gmail.com>.
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 <br...@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 <pu...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
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 <go...@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 <pu...@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
> > > > >
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Gorkem Ercan <go...@gmail.com>.
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 <br...@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 <pu...@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
> > > >
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Braden Shepherdson <br...@chromium.org>.
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 <pu...@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
> > >
> >
>
Re: tag, and accessing the plugin list
Posted by Jesse <pu...@gmail.com>.
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 <go...@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
> >
>
Re: tag, and accessing the plugin list
Posted by Anis KADRI <an...@gmail.com>.
Yeah why ?
On Wed, Nov 13, 2013 at 11:38 AM, Gorkem Ercan <go...@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 <br...@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
>>
Re: tag, and accessing the plugin list
Posted by Gorkem Ercan <go...@gmail.com>.
Hey Braden,
Why is not the current <feature> tags sufficient for this?
--
Gorkem
On Wed, Nov 13, 2013 at 2:32 PM, Braden Shepherdson <br...@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
>