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 <anis.ka...@gmail.com> wrote: > no we just all responded at once. > > On Wed, Nov 13, 2013 at 1:31 PM, Braden Shepherdson <bra...@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 <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 >>> > > > > >>> > > > >>> > > >>> > >>>
