Alright. How about 4:30 PM EST UTC-5 ? Whomever is interested can join up to the 10 participants limit.
On Thu, Nov 14, 2013 at 11:25 AM, Braden Shepherdson <bra...@chromium.org> wrote: > I'm definitely willing to jump on a Hangout this afternoon. Anytime from > now through about three hours from now works for me. > > Braden > > > On Thu, Nov 14, 2013 at 2:19 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > >> Let's google hangout about this and report back to the list yeah ? >> >> My main concern is user confusion like here [1]. When a plugin fails >> to load/work, people start looking around config files and wonder why >> it's broken and I feel like the more config stuff we add the more >> confusion it creates. >> >> [1] https://github.com/imhotep/MapKit/issues/18#issuecomment-25952856 >> >> On Thu, Nov 14, 2013 at 10:53 AM, Braden Shepherdson >> <bra...@chromium.org> wrote: >> > I apologize for getting somewhat short in my previous email. >> > >> > Let me explain my comment on needing "more, and more hacky, code". >> Because >> > of how Plugman parses the <config-file> tags and makes the edits to the >> XML >> > files, it would require special-case logic to find <feature> tags and >> > inject this extra information into them. Only some <config-file> tags are >> > pointing at the right file and XPath, and this would have Plugman >> examining >> > the children of <config-file> tags instead of treating it as a black box >> > and copying it in. My proposal of injecting new tags doesn't require >> > anything like that, Plugman just adds an extra config-munge entry for >> each >> > plugin, after it's finished parsing the <config-file> tags. The patch to >> > implement this only added a few lines. >> > >> > This information is being injected by Plugman into the platform >> config.xml >> > (the build artifact) at plugman-prepare time. It isn't visible directly >> to >> > plugin devs, app devs, or users. But it allows an app or plugin dev who >> > wants to know what plugins are installed to find out. This allows >> checking >> > for an optional dependency, and lets AppHarness check compatibility of >> its >> > own plugins with those required by a child app. >> > >> > Braden >> > >> > >> > >> > >> > >> > On Thu, Nov 14, 2013 at 1:44 PM, 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 >> >> > > > > >> > > > > > >> > > > > > > > >> >> > > > > >> > > > > > >> > > > > > > >> >> > > > > >> > > > > > >> > > > > > >> >> > > > > >> > > > > > >> > > > > >> >> > > > > >> > > > > > >> > > > >> >> > > > > >> > > > > > >> > > >> >> > > > > >> > > > > > >> > >> >> > > > > >> > > > > > >> >> >> > > > > >> > > > > > >> >> > > > > >> > > > > > >> >> > > > > >> > > > > >> >> > > > > >> > > > >> >> > > > > >> > > >> >> > > > > >> > >> >> > > > > >> >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> >>
