I think this is the pragmatic way. Perhaps our path to JSON support will be some soft of analogue to the XML (so either works). This is more for future friendliness than anything else. Given Chrome apps, FxOS apps, etc it would appear manifests are going JSON. But whatever!
Anyhow, thanks for the thought going into this guys. Definitely cleaner/saner. On Thu, Sep 5, 2013 at 11:21 AM, Michal Mocny <mmo...@chromium.org> wrote: > We briefly discussed JSON and the two thoughts were: > > (1) We like it, but really what does it buy us? > (2) This change is at the moment 100% compatible with all current workflows > (including upgrades from 3.0->3.1), and we think that's important for > headache-less adoption. JSON would obviously not be. > > > Regarding where to store the defaults, we had thought it would be a file > bundled with the platform, perhaps in bin/templates? > > -Michal > > > On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux <b...@brian.io> wrote: > > > The logic flow is much safer in this method. Where do you think > default.xml > > should live? (Maybe it doesn't have to exist and defaults can just be > vars > > in the logic that does the processing?) > > > > Is this our opportunity to move to JSON? > > > > > > On Thu, Sep 5, 2013 at 8:21 AM, Braden Shepherdson <bra...@chromium.org > > >wrote: > > > > > config.xml as a build artifact for less suffering and easier upgrades > > > Terminology > > > > > > - > > > > > > “platform config.xml” refers to the platform-specific config.xml > > files, > > > eg. platforms/android/res/xml/config.xml. This is the final file > read > > by > > > Cordova at runtime. > > > - > > > > > > “app config.xml” refers to the top-level config.xml found in > > > www/config.xml. > > > > > > Why the current situation is suffering > > > > > > - > > > > > > Chiefly, the platforms/foo/.../config.xml files are both the input > and > > > output of munging by Plugman and the user. This sucks. It makes > > > automatic upgrades difficult because everybody has a customized > > > config.xml > > > file in their platforms. It also makes plugin rm harder and less > > robust > > > in > > > CLI than it needs to be. > > > - > > > > > > Currently only some tags in the app config.xml are actually > honoured. > > > Others are ignored, and this has tripped up our users. > > > > > > > > > Goals > > > > > > - > > > > > > bin/create workflow is unchanged. > > > - > > > > > > Final content of the platform config.xml file is unchanged, though > the > > > method of building it in the CLI can change. > > > - > > > > > > CLI workflow is unchanged, in terms of what a user types. > > > - > > > > > > platform config.xml stops being both input and output under CLI. > Less > > > munging, and easier upgrades. In short, platform config.xml files > > become > > > build artifacts. > > > > > > What we propose to do about it > > > > > > - > > > > > > First, adjust the platform template (used by bin/create) to contain > > two > > > files: > > > - > > > > > > defaults.xml, which is versioned, immutable, and tucked away > > > somewhere (only CLI accesses it) and contains only the > > > Cordova-specified > > > platform defaults, such as the preferences, any default > > > whitelist entries, > > > etc. It does NOT contain any <author>, <name> or other such tags. > > > - > > > > > > platform config.xml, which is the same as it currently is, a > > complete > > > config.xml for the HelloWorld app. This means behavior is > unchanged > > > for people who are not using CLI. Plugman still munges this file > > and > > > outputs back to it, same as now. > > > - > > > > > > Second, adjust the CLI’s cordova create template so that its > top-level > > > app config.xml contains <name>, <author>, <content>, etc. - tags the > > > user is likely to edit. > > > - > > > > > > Third, modify the CLI so that the new cordova prepare flow is: > > > - > > > > > > Delete the old platform config.xml. > > > - > > > > > > Copy the defaults.xml to config.xml. > > > - > > > > > > Re-run the Plugman config munging for every plugin, modifying the > > > fresh platform config.xml. (The order here is deliberately > > undefined; > > > plugins should already not be relying on this.) > > > - > > > > > > Run the config munging for the app’s config.xml as well. > > > - > > > > > > This results in a freshly built, build-artifact platform > > config.xml. > > > Users should not be editing it; their top-level app config.xml > > > has the last > > > word and will override any settings the defaults or plugins might > > > make. > > > - > > > > > > Note that this means we shouldn’t be needlessly setting > defaults > > > in the app config.xml, since this might prevent plugins from > > > changing > > > things that need changing. > > > - > > > > > > Fourth, extend the app config.xml format so that it can have > > > <platform>tags, like a plugin.xml. > > > - > > > > > > Into this it can put platform-specific things like splashscreens, > > > preferences and other things, rather than mixing these together > in > > > the > > > config. > > > - > > > > > > In particular, it can have <config-file> tags in the usual format > > > > > >
