Alright, I've landed a defaults.xml for ios and android and closed the long standing bugs for this.
Aside from removing the <access> tag, I also removed the settings which are overwritten by the app-level config anyway, such as app name, description, <content> tag, etc. Please take a look if you have any concerns. I did leave the default platform preferences/features in there, because those can be overridden in the app config and many really are platform specific. Tested using both the CLI and bin/create workflows to make sure both still work and do what we intent. Now, when a CLI user makes changes to the app config to remove <content> or <access> tags, the final platform config actually reflects those changes. Win. -Michal On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams <[email protected]>wrote: > +1 > > This is all sounding great and no matter how much I love the CLI, > supporting both workflows is important. > > > > > On 5 Dec 2013, at 6:13 am, Michal Mocny <[email protected]> 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 <[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.. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > >
