Didn't recommend anything. Just seeing how the impact is. Didn't think of the native bits (the native code that has some js that they call into)
On Wed, Nov 13, 2013 at 3:43 PM, Jesse <purplecabb...@gmail.com> wrote: > Currently installing the plugin org.apache.cordova.device will add a > different feature tag for each platform/project's config.xml. > <!-- firefoxos --> > <feature name="Device"> > <param name="firefoxos-package" value="Device" /> > </feature> > > <!-- android --> > <feature name="Device" > > <param name="android-package" value="org.apache.cordova.device.Device"/> > </feature> > > <!-- ios --> > <feature name="Device"> > <param name="ios-package" value="CDVDevice"/> > </feature> > > <!-- blackberry --> > <feature name="Device" value="Device"/> > <!-- wp7 and wp8 --> > <feature name="Device"> > <param name="wp-package" value="Device"/> > </feature> > > Also, presumably, the following can be used on ALL without conflict: > > <feature name="Device" value="Device"> > <param name="firefoxos-package" value="Device" /> > <param name="android-package" value="org.apache.cordova.device.Device"/> > <param name="ios-package" value="CDVDevice"/> > <param name="wp-package" value="Device"/> > </feature> > > It would be nice if blackberry supported the feature/param@name > ='bb-package' > but I don't think this is imperative. > > We are missing a couple points from Braden: > a) js only plugins do not have config.xml entries > b) one plugin may add multiple features ( not sure if this has ever > happened in practice, it may be easier to just force the plugin developer > to make their class have a single point of contact in the features list, > and delegate in their own code. ) > > Shaz's recommendations break everything everywhere from what I can tell. > This would require changes to all existing plugins, AND all platform > bridges native bits, and cordova-js. I don't think we want to be this > destructive. > > > @purplecabbage > risingj.com > > > On Wed, Nov 13, 2013 at 3:11 PM, Shazron <shaz...@gmail.com> wrote: > > > Let's see the impact of using ID as name > > > > 1. plugin.xml feature tag, name attribute -> change the value to the > plugin > > id. Or just remove the attribute, plugman can inject the plugin id > > automatically(?) so it is less error-prone - not sure > > 2. plugin's js -> change all service names to ID in cordova.exec > > > > For user upgrades, they would remove the old plugin, then add the new > one - > > so it's relatively painless I think. > > > > > > On Wed, Nov 13, 2013 at 2:47 PM, Brian LeRoux <b...@brian.io> 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 <s...@adobe.com> > > wrote: > > > > > > > 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 > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > >
