First thing: might as well give up on referencing config.xml as a standard. That's a historical footnote of little relevance anymore!
It feels leaky to define the mapping in <feature>. Would seem to me that <feature> is a userland thing from a user perspective I want to know about the ID and VERSION and the guts of what happens under the hood is none of business. No? On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson <bra...@chromium.org>wrote: > I'm going to try to summarize some points so we can get on the same page. > > tl;dr: see the last two paragraphs for what I'm actually proposing. > > First, background on why we have <feature> tags. They map a bridge name > (eg. "FileTransfer" on all platforms) used with cordova.exec() to the > native code module that implements the plugin (eg. > "org.apache.cordova.filetransfer.FileTransfer" on Android, > "CDVFileTransfer" on iOS, etc.). The native side of the bridge uses this > information to load and call the right plugin's implementation after a > cordova.exec() call. > > Note that a plugin can define 0 or more <feature> tags. Plugins with no > native code won't have one. In principle, a plugin can have more than one, > though we can't think of any examples of that. > > When I first looked at this problem of wanting to know, at runtime, what > plugins are installed, I originally considered using cordova_plugins.js to > learn the information. There are two problems here. One, the file doesn't > include information about plugin id and version. We could add it, but the > second problem is that cordova_plugins.js maps <js-module> names (used with > cordova.require()) to file names. Here again any one plugin can have 0 or > more <js-modules>; many have several. > > I then considered using the <feature> tags. The same problems apply here: > they don't map 1-1, and don't have the data we need. > > Others in the thread have proposed adding this data to the <feature> tags, > and adding <feature> tags automatically for plugins that don't already have > one (or alternatively, adding a new, autogenerated <feature> for every > plugin). The problem here is that the various native platforms are > expecting each <feature> to define a bridge name -> native code module > mapping, and these new ones won't do so. This is a potentially > bug-introducing change, because we'll have to make sure every platform can > handle these new tags which aren't like the old ones. > > All of this led to my original proposal: add a new top-level tag, > <plugins>, whose children are exactly one <plugin id="..." version="..." /> > for every plugin installed on this platform. We would then have two > separate lists in config.xml, but they are listing different things (bridge > mappings vs. plugins) for different purposes. Since this is an addition, > the platforms that don't support the new tag will just ignore it safely. > > I realize that the top-level <plugins> tag is something we had previously, > before moving to the W3C <widget> spec's <feature> tags instead. I'm > perfectly willing to change the name, to perhaps <installed-plugins>, to > avoid any confusion with the old <plugins> tag. Any better suggestions for > the names? > > > Braden > > > > On Wed, Nov 13, 2013 at 7:25 PM, Shazron <shaz...@gmail.com> wrote: > > > 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 > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
