Name is what is used in Javascript so it would be pretty painful to use and just like Gorkem said having multiple <feature>s for the same plugin is a non issue if they enclose <param name="plugin_id"...> and <param name="version"....>
On Wed, Nov 13, 2013 at 2:47 PM, Brian LeRoux <[email protected]> wrote: > 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 >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> >> >>
