Brian, I think you're a bit confused about which information is in what files. I can break that down here if people would find it valuable.
That timing works for me, Anis. I'll see you, and any other interested parties, there and then. If you're not Anis, add +Braden Shepherdson ahead of time and I'll make sure you get added into the Hangout. Braden On Thu, Nov 14, 2013 at 2:36 PM, Brian LeRoux <b...@brian.io> wrote: > This is helpful. I think my impedance mismatch here is how we ended up with > plugin.xml information (bridge mappings) in a user config file while ID and > VERSION ended up in a generated file. I know we aren't interested in > changing stuff that already works but I like to fully understand where we > are at. In any case, throwing this in an already generated file makes > perfect sense for this particular case. For some reason I thought we were > proposing another new config file which, hopefully, does not become > necessary. > > In other words: +1 > > (This said, I would like to keep rolling on the other config file > discussion to see if it is possible to consolidate that mess into something > more maintainable.) > > > > On Thu, Nov 14, 2013 at 10:44 AM, Andrew Grieve <agri...@chromium.org > >wrote: > > > I'm going to attempt to summarize in point form: > > > > Goal: > > - Make available the list of installed plugins and their versions to > > native side & JS side. > > - Needed by App Harness to know whether an app is compatible with its > > bundled set of plugins. > > > > Using cordova_plugins.js: > > - It doesn't have the information that we need > > - We could add the extra information, but not easily since the file > > exports an array instead of an object. > > - This file is not currently parsed by the native layer, so having the > > info here would be an extra IO on start-up. > > > > Using config.xml: > > - It doesn't have the information that we need > > - This is always loaded by native sides, so it's a nice fit. > > > > Using <feature>: > > - These are for defining Bridge channels > > - Plugins define 0 or more of these > > - Adding empty ones for plugins that don't define them causes exceptions > > in the native layer. We'd like this change to not break older versions of > > cordova. > > > > So, although it seems like <feature> would make sense, we've already used > > <feature> to mean something else (bridge channels). > > > > I think Braden's suggestion of adding a new tag is the simplest, both > > implementation-wise, as well as semantically (it has a single, > well-defined > > purpose). What I especially like about it, is that it separates which > tags > > are written by plugin devs (<feature>) from tags that are generated by > > plugman (<cordova-plugin>) > > > > > > > > > > > > On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > Ok, everybody be calm. We are adults and we are capable of working > > through > > > this in a dispassionate manner and has nothing to do with you, your > code, > > > or whatever. We all just want to find the best solution. Blankets > > > statements like 'more hacky code' does no good. Let's just stick to > > factual > > > stuff and stay away from subjective identification. Ok? > > > > > > "as to leaking into userland, these <feature> tags are relevant to > plugin > > > developers" ... so would this particular information belong to > > > plugin.xml???? > > > > > > Also, Joe had a good question earlier. Despite all this problem > solving I > > > have no idea what the actual problem is we are trying to solve. We have > > > lots of solutions but what precisely do our users gain from runtime > > > introspection here? > > > > > > > > > > > > > > > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson < > > bra...@chromium.org > > > >wrote: > > > > > > > Brian, as to leaking into userland, these <feature> tags are relevant > > to > > > > plugin developers, since they have to define the mapping of exec > names > > to > > > > native files so we can load their plugins. None of this is visible to > > app > > > > developers or end users. > > > > > > > > We're not paying by the byte, or the top-level tag, in config.xml. NB > > > that > > > > this is the platform config.xml, the one that's a build artifact no > one > > > but > > > > the platform code is ever supposed to look at. Why are we sweating so > > > hard > > > > over adding some new information into the file, and trying to > shoehorn > > it > > > > into existing tags? The code to handle this is simpler in Plugman and > > on > > > > the platforms to have this be a separate tag, rather than mixing it > in > > > with > > > > <feature>. > > > > > > > > If we want to use <feature> tags for this, despite it requiring more, > > and > > > > more hacky, code all around, we're going to need a good reason. I > > haven't > > > > heard any reason for why using <feature> gains us anything. > > > > > > > > Carlos, as I noted in my remixed proposal above, I originally wanted > to > > > use > > > > cordova_plugins.js or a similar www/ file for this, but there are > > > problems > > > > with that. On the other hand, I would much rather add a new file that > > can > > > > be loaded as a js-module than do this using hacked-up <feature> tags. > > > > > > > > Braden > > > > > > > > > > > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <don.cole...@gmail.com > > > > > > wrote: > > > > > > > > > JavaScript only plugin implementations are valid on BlackBerry 10. > > Some > > > > > things that require native code on Android can be implemented in > > client > > > > > side JavaScript on BlackBerry using com.blackberry.invoke. > > > > > > > > > > > > > > > On Thu, Nov 14, 2013 at 12:26 PM, Joe Bowser <bows...@gmail.com> > > > wrote: > > > > > > > > > > > On Thu, Nov 14, 2013 at 9:12 AM, Brian LeRoux <b...@brian.io> > wrote: > > > > > > > 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? > > > > > > > > > > > > > > > > > > > This is actually where the mapping happens right now, and I > really > > > > > > don't want to change this, since changing mapping would break > > > > > > EVERYTHING. That being said, I don't know why we can't have > > feature > > > > > > tags with no *-package params. That being said, I'm not sure > what > > > the > > > > > > point would even be, since JS-only plugins aren't really plugins > at > > > > > > all and are just Javascript libraries. Are there current > examples > > of > > > > > > this in Cordova currently? > > > > > > > > > > > > > > > > > > > > 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 > > > > > > >> > > > > > >> > > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > > >> > > > > > >> > > > > > > > > > > >> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > >> > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
