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 DE485100FD for ; Tue, 3 Dec 2013 20:14:18 +0000 (UTC) Received: (qmail 7289 invoked by uid 500); 3 Dec 2013 20:14:18 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 7268 invoked by uid 500); 3 Dec 2013 20:14:18 -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 7260 invoked by uid 99); 3 Dec 2013 20:14:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 20:14:18 +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.179 as permitted sender) Received: from [209.85.192.179] (HELO mail-pd0-f179.google.com) (209.85.192.179) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Dec 2013 20:14:14 +0000 Received: by mail-pd0-f179.google.com with SMTP id r10so20691444pdi.24 for ; Tue, 03 Dec 2013 12:13:53 -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=KDyFHyTT+X9aWagDQ9RsU5GSLl1Ml7MQnQ6OFEWZoi4=; b=j3eAVnjfkM8tzD9ZEYJUmmsWr+8hlEFNNKQI9Ung8cdHdbhbg3bm31b7Gsbp7R3iCJ 9z1p3aBvv9VYYgqsXsCsLPHoBv2+a/d7vqzzX2Bi2EWFKg0uDUkbbCp4j8AiWR6S6ujK Syp1ZcbnUddw1hDEdUfCfh0bhkd2PKvb1yBf2uKYwLdMqG8PukS30KqHm5JLCw0MEghT 77hRdC+iv+cy9L2DLUmwr21Mofi98N7qbdOnLyZReqOkPG5gjy5DzqowiHkr6l2JGADA wu4HlUAhl5fCfOWJm/dXMlM3cOw87hfvztdDMbmF7a9c/r10CBwPXlwSHU97HQTjXwla a3vA== X-Gm-Message-State: ALoCoQmM/xtTQHt+qSITa1f6zAVlIg8Ne2SVB13NNnuAfLdTlxkuxMHtMSuqVPV4zpiY3acY76JF X-Received: by 10.68.103.163 with SMTP id fx3mr40789302pbb.59.1386101633695; Tue, 03 Dec 2013 12:13:53 -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 qz9sm130788482pbc.3.2013.12.03.12.13.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 12:13:52 -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: Wed, 4 Dec 2013 07:13:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2266FED4-4870-4832-A00A-401BCEA4A921@devgeeks.org> References:

To: dev@cordova.apache.org X-Mailer: Apple Mail (2.1812) X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: > 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 = 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 = >>> 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 >> 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 >>>>> 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