Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of mmocny@google.com designates
 209.85.214.180 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CADVgkyNrLHZ+3EsOq4y4s+HMsEh-CKjSmuUsUhJAd3W9UPtKHA@mail.gmail.com>
References: 
 <CAMk5LLme8qdFkvGxJ9+CKtX1kvfvG5kipzYxyyQXyo-TDmw9bQ@mail.gmail.com>
 <CADVgkyNrLHZ+3EsOq4y4s+HMsEh-CKjSmuUsUhJAd3W9UPtKHA@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Thu, 5 Sep 2013 14:21:06 -0400
Message-ID: 
 <CAEeF2Tc_zq6OAjPCvTu1BMiQCL9Mr_RgsAVVBY9QnJ8JAk9q-w@mail.gmail.com>
Subject: Re: config.xml as a build artifact for less suffering and easier
 upgrades
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c33676714c4b04e5a6fdbd

--001a11c33676714c4b04e5a6fdbd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

We briefly discussed JSON and the two thoughts were:

(1) We like it, but really what does it buy us?
(2) This change is at the moment 100% compatible with all current workflows
(including upgrades from 3.0->3.1), and we think that's important for
headache-less adoption.  JSON would obviously not be.


Regarding where to store the defaults, we had thought it would be a file
bundled with the platform, perhaps in bin/templates?

-Michal


On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux <b@brian.io> wrote:

> The logic flow is much safer in this method. Where do you think default.x=
ml
> should live? (Maybe it doesn't have to exist and defaults can just be var=
s
> in the logic that does the processing?)
>
> Is this our opportunity to move to JSON?
>
>
> On Thu, Sep 5, 2013 at 8:21 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > config.xml as a build artifact for less suffering and easier upgrades
> > Terminology
> >
> >    -
> >
> >    =93platform config.xml=94 refers to the platform-specific config.xml
> files,
> >    eg. platforms/android/res/xml/config.xml. This is the final file rea=
d
> by
> >    Cordova at runtime.
> >    -
> >
> >    =93app config.xml=94 refers to the top-level config.xml found in
> >    www/config.xml.
> >
> > Why the current situation is suffering
> >
> >    -
> >
> >    Chiefly, the platforms/foo/.../config.xml files are both the input a=
nd
> >    output of munging by Plugman and the user. This sucks. It makes
> >    automatic upgrades difficult because everybody has a customized
> > config.xml
> >    file in their platforms. It also makes plugin rm harder and less
> robust
> > in
> >    CLI than it needs to be.
> >    -
> >
> >    Currently only some tags in the app config.xml are actually honoured=
.
> >    Others are ignored, and this has tripped up our users.
> >
> >
> > Goals
> >
> >    -
> >
> >    bin/create workflow is unchanged.
> >    -
> >
> >    Final content of the platform config.xml file is unchanged, though t=
he
> >    method of building it in the CLI can change.
> >    -
> >
> >    CLI workflow is unchanged, in terms of what a user types.
> >    -
> >
> >    platform config.xml stops being both input and output under CLI. Les=
s
> >    munging, and easier upgrades. In short, platform config.xml files
> become
> >    build artifacts.
> >
> > What we propose to do about it
> >
> >    -
> >
> >    First, adjust the platform template (used by bin/create) to contain
> two
> >    files:
> >    -
> >
> >       defaults.xml, which is versioned, immutable, and tucked away
> >       somewhere (only CLI accesses it) and contains only the
> > Cordova-specified
> >       platform defaults, such as the preferences, any default
> > whitelist entries,
> >       etc. It does NOT contain any <author>, <name> or other such tags.
> >       -
> >
> >       platform config.xml, which is the same as it currently is, a
> complete
> >       config.xml for the HelloWorld app. This means behavior is unchang=
ed
> >       for people who are not using CLI. Plugman still munges this file
> and
> >       outputs back to it, same as now.
> >       -
> >
> >    Second, adjust the CLI=92s cordova create template so that its top-l=
evel
> >    app config.xml contains <name>, <author>, <content>, etc. - tags the
> >    user is likely to edit.
> >    -
> >
> >    Third, modify the CLI so that the new cordova prepare flow is:
> >    -
> >
> >       Delete the old platform config.xml.
> >       -
> >
> >       Copy the defaults.xml to config.xml.
> >       -
> >
> >       Re-run the Plugman config munging for every plugin, modifying the
> >       fresh platform config.xml. (The order here is deliberately
> undefined;
> >       plugins should already not be relying on this.)
> >       -
> >
> >       Run the config munging for the app=92s config.xml as well.
> >       -
> >
> >       This results in a freshly built, build-artifact platform
> config.xml.
> >       Users should not be editing it; their top-level app config.xml
> > has the last
> >       word and will override any settings the defaults or plugins might
> > make.
> >       -
> >
> >          Note that this means we shouldn=92t be needlessly setting defa=
ults
> >          in the app  config.xml, since this might prevent plugins from
> > changing
> >          things that need changing.
> >          -
> >
> >    Fourth, extend the app config.xml format so that it can have
> > <platform>tags, like a plugin.xml.
> >    -
> >
> >       Into this it can put platform-specific things like splashscreens,
> >       preferences and other things, rather than mixing these together i=
n
> > the
> >       config.
> >       -
> >
> >       In particular, it can have <config-file> tags in the usual format
> >
>

--001a11c33676714c4b04e5a6fdbd--