If I remember correctly, that isn't a change for the policy - it's just that most platforms don't have a defaults.xml yet.
My intention with the defaults.xml change has always been that we ship both files, and maintain both files, since they're consumed by the different workflows in different ways. That could probably have been better-communicated, and we should have pushed more firmly for getting defaults.xml files added to all platforms. Braden On Wed, Dec 4, 2013 at 11:13 AM, Michal Mocny <mmo...@chromium.org> wrote: > 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 <bra...@google.com > >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" <mmo...@chromium.org> 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 <agri...@chromium.org> > > > wrote: > > > > > > > Michal - I'm not s > > > > > > > > > > > > On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams < > > > to...@devgeeks.org > > > > >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 <mmo...@chromium.org> > 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 < > to...@devgeeks.org > > > > > > > > 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" <mmo...@chromium.org> > > wrote: > > > > > >> > > > > > >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson < > > > > > bra...@chromium.org > > > > > >>>> 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 < > mmo...@google.com > > > > > > > > >> 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.. > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > >
