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
<bra...@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 <purplecabb...@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.er...@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 <bra...@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
>> > >
>> >
>>
