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 <anis.ka...@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
> <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
> >> > >
> >> >
> >>
>
