Brian: plugin mapping "service js name" -> "service native name/class"
On 11/13/13 2:36 PM, "Brian LeRoux" <b...@brian.io> wrote: >what are we using <feature> for? > > >On Wed, Nov 13, 2013 at 2:27 PM, Braden Shepherdson ><bra...@google.com>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" <gorkem.er...@gmail.com> 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 >><bra...@chromium.org >> > >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 >><gorkem.er...@gmail.com >> > > >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 < >> > 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 >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >>
