... a meeting about this thread even! ;) @purplecabbage risingj.com
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 > > > > > > > > > > > > > > > > > > > > >
