Yes, there is no need to change the tools, which is why I like this approach. I forgot to mention that part :P
I did not think we previously discussed supplying both config files with different default settings. I had previously imagined we would ship platforms with only one defaults file (defaults.xml/config.xml whichever name) that was consumed by both flows. The function of a defaults.xml was as an implementation detail of CLI to help us treat config.xml as a build artifact. Now I am proposing using it as a first class config file that gets maintained along with config.xml in platform releases. -Michal On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <[email protected]>wrote: > It's possible I'm misunderstanding something here, but the flow you > described here is exactly the one we intended when designing how > details.xml was going to work. Platforms ship both files, cli uses > defaults.xml where available, and config.xml where not. Platform scripts > use config.xml always. > > I don't think any (many?) Changes to the tools will be necessary to support > this. > > Braden > On Dec 4, 2013 8:25 AM, "Michal Mocny" <[email protected]> wrote: > > > Alright, Andrew and I discussed this and think we have a resolution that > > works with all the use cases (yay for options). > > > > TLDR; I think we already (accidentally?) support using a different > default > > platform config file for each of our two workflows. This means we can > have > > the <access origin="*"> tag live inside the platform config for > > platform-centric workflow, and inside the app config for app-centric > > workflow. This means users less surprise for end users, and downstream > > distributions can more sensibly override these types of defaults should > > they chose to. > > > > ---- > > > > Most platforms don't ship with a defaults.xml file yet (except for BB; > > because Jeff did this work, he followed through for that platform). > There > > are open bugs to add these (ie, CB-5047). > > > > Jeff also added a nice fallback to the CLI: if there does not exist a > > defaults.xml when running "prepare", backup the initial config.xml to a > > defaults.xml file before we go messing everything up with plugin / app > > settings. Effectively the config.xml that ships with platforms is the > > defaults.xml for platforms that don't have one explicitly added. This > is a > > great default. > > > > However, if there actually were a defaults.xml, the CLI would consume > that > > for its initial input in the prepare process, and completely ignore the > > platform config.xml. The bin/create script would completely ignore the > > defaults.xml file and use only the config.xml file. > > > > So, if we shipped both a config.xml *and* defaults.xml, we could choose > > which settings to set for each workflow. I don't actually think the > > settings should generally differ, and its mildly annoying that we would > > have mostly duplicated files, but it means we can move such "optional" > > settings as <access> or <dependency> etc out of the platform config, and > > into the default app config which lives in cordova-cli, since that is > where > > users of the CLI expect them to be. > > > > Note that I think this is important & good because for users of the > > platform workflow, they expect to make changes directly to platform > > config.xml, but for users of the CLI, we keep harping at them to never > edit > > those files, yet thats the only way at the moment to remove these > optional > > defaults we inject for them. > > > > WDYT? I'm working on a prototype and will report back if the theory > works > > in practice. > > > > -Michal > > > > > > > > On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve <[email protected]> > > wrote: > > > > > Michal - I'm not s > > > > > > > > > On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams < > > [email protected] > > > >wrote: > > > > > > > Absolutely agree. > > > > > > > > +1 for * as default, but just as importantly, +1 for never having to > > hax > > > > inside ./platforms/**/* for this stuff. > > > > > > > > We are already forced to use hooks to enforce ./platforms as a build > > > > artefact. Any progress towards the great goal of being able to safely > > > > .gitignore the platforms make me feel warm and fuzzy. ;) > > > > > > > > > > > > > > > > On 4 Dec 2013, at 7:09 am, Michal Mocny <[email protected]> wrote: > > > > > > > > > Tommy, absolutely the default should remain *, as I said. > > > > > > > > > > But I hope we can agree that it should also be possible to override > > the > > > > > default without requiring hacks. iOS already supports this, so > its a > > > > > matter of feature parity. > > > > > > > > > > -Michal > > > > > > > > > > > > > > > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams <[email protected] > > > > > > wrote: > > > > > > > > > >> Please don't go back to when every new dev had to struggle with > the > > > > Google > > > > >> group or irc to find out why their ajax requests didn't work. > > > > >> > > > > >> There was a huuuuge discussion at the time that we chose to > default > > > to * > > > > >> On 04/12/2013 6:03 am, "Michal Mocny" <[email protected]> > wrote: > > > > >> > > > > >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson < > > > > [email protected] > > > > >>>> wrote: > > > > >>> > > > > >>>> There are two different files here: one is defaults.xml, which > the > > > CLI > > > > >>>> takes as the basis for its platform config.xml. The other is the > > > > >>> config.xml > > > > >>>> that you get after running bin/create. In the CLI world, that > > second > > > > >> file > > > > >>>> is immediately overwritten by one created from defaults.xml, the > > > > >>> top-level > > > > >>>> app config.xml, etc. > > > > >>>> > > > > >>> > > > > >>> Okay, thats what I thought we were doing, but I cannot find > > where/how > > > > the > > > > >>> defaults.xml is created in the first place. I see now that it > does > > > > exist > > > > >>> in my CLI projects, but seems not to exist inside our platforms > nor > > > > CLI, > > > > >>> nor can I find the code that generates it. > > > > >>> > > > > >>> > > > > >>>> > > > > >>>> I support the second point of removing the <access origin="*" /> > > > from > > > > >> the > > > > >>>> CLI's hello world template app; it should be turned into a > > comment. > > > > >>>> > > > > >>> > > > > >>> Seems this is redundant anyway given that the platforms provide > > this > > > > as a > > > > >>> default. Regarding leaving it in as a comment: should we embed > the > > > > full > > > > >>> spec as a comment? If not, I would just leave a general > > description > > > > and > > > > >>> link to the spec docs online. > > > > >>> > > > > >>> > > > > >>>> I don't think we should be including <access origin="*" /> by > > > default > > > > >>>> anywhere, unless we really do want to disable the whitelist on > > that > > > > >>>> platform. And if we do want to disable it, why not in the native > > > code > > > > >>>> instead of allowing everything by default? > > > > >>>> > > > > >>> > > > > >>> I remember about a year ago we had a bunch of talks regarding the > > > > default > > > > >>> whitelist, and decided that almost every developer doesn't want > to > > > use > > > > a > > > > >>> whitelist and wants every request to be allowed by default. For > > > those > > > > >> few > > > > >>> devs that want this (false?) sense of security they can learn how > > to > > > > >>> opt-in, instead of having the same question on the user lists > over > > > and > > > > >> over > > > > >>> about how to opt-out. > > > > >>> > > > > >>> Changing the platforms to allow * by default is an interesting > > idea, > > > > but > > > > >> I > > > > >>> would rather see a solution that doesn't need that change. Plus > > its > > > a > > > > >> bit > > > > >>> less semantic/declarative aka more magical/surprising. > > > > >>> > > > > >>> > > > > >>>> > > > > >>>> Braden > > > > >>>> > > > > >>>> > > > > >>>> On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny <[email protected] > > > > > > >> wrote: > > > > >>>> > > > > >>>>> On ios, the default config.xml file (aka the platform defaults) > > is > > > > >>>> bundled > > > > >>>>> as part of the ios project template, and the project template > is > > > easy > > > > >>> to > > > > >>>>> override using flags to create script / CLI config options. > > Easy, > > > > >>> great. > > > > >>>>> > > > > >>>>> For android, the default config.xml file is bundled with the > > > platform > > > > >>>>> framework itself and not as part of the project template. I > > assume > > > > >>> this > > > > >>>> is > > > > >>>>> not easy to fix, otherwise we would have made the change > already? > > > > >>>>> > > > > >>>>> Since the <access> tag is additive (i.e. cannot just override > it > > by > > > > >>>>> appending), there is no way to remove that default without > > reaching > > > > >> in > > > > >>>> and > > > > >>>>> editing cordova-android/framework/res/xml/config.xml file > > directly > > > > >>>> (either > > > > >>>>> with a custom post-platform-add hook to run sed, or by forking > > > > >>>>> cordova-android to change the default, both shitty options > imho). > > > > >>>>> > > > > >>>>> Any suggestions on how to fix this? > > > > >>>>> > > > > >>>>> I was hoping to propose that we move the tag out of all the > > > platform > > > > >>>>> templates and instead add it to the hello-world app template -- > > > but I > > > > >>>> think > > > > >>>>> that won't work well with the platform-scripts workflow since > > that > > > > >> flow > > > > >>>>> doesn't use an application level config.xml at all right now. > > > > > > > > > > I like your suggestion here actually. > > > - Take <access> out of defaults.xml, and leave it in CLI's config.xml > > > template > > > - Leave <access> in template's config.xml > > > > > > That will mean: > > > - for non-CLI projects, it will be there by default, and users can edit > > it > > > directly > > > - for CLI projects, it will be there by default due to the app's > > > config.xml, and users can edit that one to remove it. > > > > > > > > > > > > > >>>>> > > > > >>>>> > > > > >>>>> Second, related issue: cordova-cli bundles a default > application > > > > >>>> config.xml > > > > >>>>> file, which also includes <access origin="*"/>. I think this > is > > > just > > > > >>>>> unnecessary and should be removed. > > > > >>>>> > > > > >>>>> > > > > >>>>> -Michal > > > > >>>>> > > > > >>>>> p.s. as an aside, I thought we were moving the default platform > > > > >>>> config.xml > > > > >>>>> out into a file called "defaults.xml"? It seems only the good > > > folks > > > > >> at > > > > >>>>> blackberry have done that so far.. > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
