Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9EDD010E16 for ; Wed, 4 Dec 2013 19:32:23 +0000 (UTC) Received: (qmail 76938 invoked by uid 500); 4 Dec 2013 19:32:23 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 76867 invoked by uid 500); 4 Dec 2013 19:32:23 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 76859 invoked by uid 99); 4 Dec 2013 19:32:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Dec 2013 19:32:23 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tommy@devgeeks.org designates 209.85.192.180 as permitted sender) Received: from [209.85.192.180] (HELO mail-pd0-f180.google.com) (209.85.192.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Dec 2013 19:32:18 +0000 Received: by mail-pd0-f180.google.com with SMTP id q10so22982054pdj.39 for ; Wed, 04 Dec 2013 11:31:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=R5wN3aLYrXIAfmkIcWHq8jeWjYyiJMhn00KbYoIb6pM=; b=IspAi5so0XmmBJVHsl+PdO95I7I4PkxnNb/KyC3NUTv4C6LHb/b8H5/UmTdYzct/Dr 3C3jBTFf8OLHDhk6gdyXgweBW8A/V1zqbfZUhHvgbJqoDovNc7bekhHU5BNvgvxgQ8qT 6ySboMBY1hQplVs41BfVvctVE6XIw3JD3NHUS8t8cRCJ7bzw9Nsam9uiaxVVjBpc6NYC u6rwsB1IAsW2Qv1FUYIfmHSodCQLAdahR8ectydoZ9gbGsLCyiXQrIWmmLjy5eFnBsvD Fq7guaU2Z76pqCeqe3w56JGhUPcaBxFJ8lscxD3MG0u6qYjHXHwUb1TBFNvmPKtePcTM 7+hw== X-Gm-Message-State: ALoCoQlUGjKmbGn3HBMb6uBWJTwNCStsrdcTIm0nfr2eA4D01josX+VYDqSyZfhbKOKzBDVC2mMK X-Received: by 10.68.164.98 with SMTP id yp2mr40317148pbb.80.1386185518343; Wed, 04 Dec 2013 11:31:58 -0800 (PST) Received: from [192.168.1.12] (CPE-110-148-142-78.vxl8.lon.bigpond.net.au. [110.148.142.78]) by mx.google.com with ESMTPSA id vf7sm23927069pbc.5.2013.12.04.11.31.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 11:31:57 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: [android] How to remove the automatic default of From: Tommy-Carlos Williams In-Reply-To: Date: Thu, 5 Dec 2013 06:31:53 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F92826F-099D-449D-8048-F93E8A9CE995@devgeeks.org> References:

<2266FED4-4870-4832-A00A-401BCEA4A921@devgeeks.org>

To: dev@cordova.apache.org X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on apache.org +1=20 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 wrote: > Yes, there is no need to change the tools, which is why I like this > approach. I forgot to mention that part :P >=20 > 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. >=20 > -Michal >=20 >=20 > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson = wrote: >=20 >> 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. >>=20 >> I don't think any (many?) Changes to the tools will be necessary to = support >> this. >>=20 >> Braden >> On Dec 4, 2013 8:25 AM, "Michal Mocny" wrote: >>=20 >>> Alright, Andrew and I discussed this and think we have a resolution = that >>> works with all the use cases (yay for options). >>>=20 >>> 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 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. >>>=20 >>> ---- >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 or 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. >>>=20 >>> 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. >>>=20 >>> WDYT? I'm working on a prototype and will report back if the theory >> works >>> in practice. >>>=20 >>> -Michal >>>=20 >>>=20 >>>=20 >>> On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve >>> wrote: >>>=20 >>>> Michal - I'm not s >>>>=20 >>>>=20 >>>> On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams < >>> tommy@devgeeks.org >>>>> wrote: >>>>=20 >>>>> Absolutely agree. >>>>>=20 >>>>> +1 for * as default, but just as importantly, +1 for never having = to >>> hax >>>>> inside ./platforms/**/* for this stuff. >>>>>=20 >>>>> 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. ;) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4 Dec 2013, at 7:09 am, Michal Mocny = wrote: >>>>>=20 >>>>>> Tommy, absolutely the default should remain *, as I said. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> -Michal >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams = >>=20 >>>>> wrote: >>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> There was a huuuuge discussion at the time that we chose to >> default >>>> to * >>>>>>> On 04/12/2013 6:03 am, "Michal Mocny" >> wrote: >>>>>>>=20 >>>>>>>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson < >>>>> braden@chromium.org >>>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I support the second point of removing the >>>> from >>>>>>> the >>>>>>>>> CLI's hello world template app; it should be turned into a >>> comment. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I don't think we should be including = 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? >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Braden >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny = >>=20 >>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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? >>>>>>>>>>=20 >>>>>>>>>> Since the 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). >>>>>>>>>>=20 >>>>>>>>>> Any suggestions on how to fix this? >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>=20 >>>>=20 >>>> I like your suggestion here actually. >>>> - Take out of defaults.xml, and leave it in CLI's = config.xml >>>> template >>>> - Leave in template's config.xml >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Second, related issue: cordova-cli bundles a default >> application >>>>>>>>> config.xml >>>>>>>>>> file, which also includes . I think = this >> is >>>> just >>>>>>>>>> unnecessary and should be removed. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -Michal >>>>>>>>>>=20 >>>>>>>>>> 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.. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20