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 <[email protected]> wrote: > Brian: plugin mapping "service js name" -> "service native name/class" > > On 11/13/13 2:36 PM, "Brian LeRoux" <[email protected]> wrote: > > >what are we using <feature> for? > > > > > >On Wed, Nov 13, 2013 at 2:27 PM, Braden Shepherdson > ><[email protected]>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" <[email protected]> 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 > >><[email protected] > >> > >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 > >><[email protected] > >> > > >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 < > >> > [email protected] > >> > > > >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 <[email protected] > > > >> > > 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 < > >> > > [email protected] > >> > > > > > >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 < > >> > > > > [email protected] > >> > > > > > > >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 > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >
