On Mon Feb 17 04:13 PM, Jesse wrote: > If this only refers to the cli project level config, then I withdraw my > objection. >
config.json or config.xml would be top-level in the cli project > However, consistency creates clarity. > > Maybe taking a step back, why do we have different config.xml files per > platform > anyway? Given that they are all following the same spec ( > our modified widget > spec ) shouldn't they all be capable of reading > feature/param[@name="X"] and > only applying the preferences they > support? > > Everything would be generated based on what the platforms need. e.g. helloworld/config.json helloworld/platforms/windows8/config.xml helloworld/platforms/android/res/xml/config.xml helloworld/platforms/firefoxos/www/wat.json (manifest.json?, package.json?) Looking at firefoxos, only need the 'runtime meta' and pushing configuration options in there. Hopefully eventually the cordova 'meta' stuff goes away. Note: Android could be changed to read it's cordova config from "www/wat.json", ultimately that's the only 'standardish' file platform webviews/runtimes should be reading. json['meta']['cordova']['config']['log-level'] json['meta']['cordova']['config']['access-origin'][0] ... The goal of the top-level config is to have enough info to generate meta that the platforms can read. In an ideal world, there's only two files: helloworld/config.json helloworld/platforms/windows8/www/w3c-standard.json or helloworld/config.xml helloworld/platforms/windows8/www/w3c-standard.json
