Brian, I'm definitely interested in overhauling the configuration files. The reason I suggested punting, however, is that I and the Google team are chasing a launch milestone for the next few weeks. I would have much more time for drawing up ideas, discussing them, and implementing them starting in Q1. I realize that only applies to me, though, and if people want to start that discussion soon, then I'll contribute to it. I have several ideas in that direction, if we're going to do a wholesale change to our configuration setup.
Braden On Fri, Nov 15, 2013 at 5:29 PM, Michal Mocny <[email protected]> wrote: > On Fri, Nov 15, 2013 at 4:25 PM, Jonathan Bond-Caron < > [email protected]> wrote: > > > On Fri Nov 15 11:29 AM, Braden Shepherdson wrote: > > > I propose three things: > > > 1. Punt all discussion of overhauling configuration files to the new > > year. > > > 2. Drop my proposals above, as well as the summary Anis posted of last > > night's > > > discussion. > > > 3. Solve the immediate use-case of AppHarness wanting to know what > > plugins > > > are installed by injecting that object into a new key attached to the > > array of JS > > > modules in cordova_plugins.js. > > > > > > > +1 > > > > Added info about 'cordova_plugins.js' here: > > https://wiki.apache.org/cordova/ConfigurationFiles > > > > Small note to avoid confusion: the naming of the file is a bit > misleading, > > 'cordova_modules.js' is more appropriate. Since each plugin can have 1+ > > modules. > > > > Eventually might better to rename this altogether to ~ > > 'cordova_meta.js(on)' that holds generated metadata their either native > or > > JavaScript can read. > > > > Thats a good observation re modules not plugins, but with Bradens change > to add the list of plugins I think the name becomes less invalid. Either > way, not worth the change since its just an artifact the user never opens > directly. >
