On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson <bra...@chromium.org> wrote: > > 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. >
I don't see why a change in an XML parser is a huge deal. > 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 don't think we should add this plugin tag. This is just going to cause even more confusion among our users. I don't think sacrifice clarity for developer convenience. > 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? I think this should go in the feature tag so that it's clear what's going on. How is this feature supposed to help our users? > 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 >> > > > > >> > > > > > > > >> > > > > >> > > > > > > >> > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > > >> > > >> > > > > >> > >> > > > > >> >> > > > > >> > > > > >> > > > >> > > >> > >>
