+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 <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.. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>
