cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: config.xml as a build artifact for less suffering and easier upgrades
Date Mon, 16 Sep 2013 20:06:54 GMT
We don't get email notified (or, at least I don't) of github pull requests,
but we do get emails for review-board (or at least the assignee does?).
 Either way, if you post a link you'll likely get better luck with a review
quicker next time, sorry that we missed it.  I can't peek until
tomorrow/wed, so if no one gets to it, I'll do it then.

-Michal

On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz
<jheifetz@blackberry.com>wrote:

> So I believe this pull request is ready to go, however I have yet to get
> any feedback on the request itself. Can anyone familiar with the other
> platforms volunteer to test this with them?
>
> Is this a question of presentation, should I close the github pull request
> in favour of the cordova review board ?
>
> On 13-09-12 2:13 PM, "Michal Mocny" <mmocny@chromium.org> wrote:
>
> >Thats awesome, looking forward to it!
> >
> >
> >On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz
> ><jheifetz@blackberry.com>wrote:
> >
> >> Yup I'm on the same page with you Michal, and I believe Braden as well.
> >> I'm sorry I should have said so earlier, we resolved this on irc. I
> >>have a
> >> basic implementation here https://github.com/apache/cordova-cli/pull/39
> >> but I'm still testing it.
> >>
> >> On 13-09-12 12:36 PM, "Michal Mocny" <mmocny@chromium.org> wrote:
> >>
> >> >Trying to clarify the misunderstanding...
> >> >
> >> >Jeffrey, if I understand your email, your understanding of point (4) of
> >> >bradens flow is that the app.xml is *being* munged, whereas we meant
> >>that
> >> >its the app.xml config that is *doing* the munging to the platform
> >>config.
> >> > I think that means we both agree that app.xml should never be
> >>modified,
> >> >and it was just a miscommunication.  Am I right with that
> >>understanding?
> >> >
> >> >Also, in your proposal you have plugins munging/preparing *after*
> >>app.xml
> >> >does its munging. I assume you did not do intentionally, that you had
> >>just
> >> >not considered the order important.  If it was intentional, why?  We
> >>were
> >> >thinking app.xml should be last and thus have the most "importance".
> >> >
> >> >
> >> >On Wed, Sep 11, 2013 at 11:38 AM, Braden Shepherdson
> >> ><braden@chromium.org>wrote:
> >> >
> >> >> I think we've gotten a bit confused. Let me try to describe again the
> >> >>way I
> >> >> was envisioning things.
> >> >>
> >> >> 1. If defaults.xml exists, replace platform config.xml with it.
> >> >> 2. Use plugman to add each plugin's <config-file> changes onto the
> >> >>platform
> >> >> config.xml.
> >> >> 3. Add in the values from the app config.xml: <name>, <author> etc.,
> >> >>which
> >> >> it currently does, plus the proposed new <config-file> tags.
> >> >> 4. Somewhere in there, call plugman prepare to update the JS modules.
> >> >>This
> >> >> doesn't change or depend on config.xml at all.
> >> >>
> >> >> NB: I don't suggest anywhere that we edit the user's top-level, app
> >> >> config.xml. This is just a process for building the platform
> >>config.xml,
> >> >> and making it a pure build artifact.
> >> >>
> >> >> I also suggest that the "last word"; the file whose changes are added
> >> >>last,
> >> >> is the app config.xml. This allows the user the power to override any
> >> >> default or setting from a plugin.
> >> >>
> >> >> Braden
> >> >>
> >> >>
> >> >> On Wed, Sep 11, 2013 at 2:16 PM, Jeffrey Heifetz
> >> >><jheifetz@blackberry.com
> >> >> >wrote:
> >> >>
> >> >> > I'd like to clarify the changes to prepare before I continue the
> >> >> > implementation.
> >> >> >
> >> >> > The current prepare flow works like this
> >> >> >         1. Call parser.update_project. This includes calling
> >> >> > parser.update_from_config which updates the platform config and
> >> >>resources
> >> >> > based on app config (but only handles specific tags). It also
> >>updates
> >> >>the
> >> >> > platform www based on app www, staging and overrides.
> >> >> >         2. Call plugman prepare (sets up JS-modules)
> >> >> >         3. Plugin config-munge (where each plugin config changes
> >>are
> >> >> > iterated
> >> >> > through)
> >> >> >
> >> >> > Braden's proposed flow (in his own words)
> >> >> >         1. Delete the old platform config.xml.
> >> >> >         2. Copy the defaults.xml to config.xml.
> >> >> >         3. 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.)
> >> >> >         4. Run the config munging for the app’s config.xml as well.
> >> >> > Where I believe #4 means the plugin config-munge.
> >> >> >
> >> >> > I'd like to propose the new flow to be the following
> >> >> >
> >> >> >         1. If defaults.xml exists, replace platform congig.xml
> >>with it
> >> >> >         2. Run a generic clobbers from app.xml to platform.xml that
> >> >>will
> >> >> > include
> >> >> > processing the proposed <platform> tags.
> >> >> >         3. Run plugman config munge on the platform config.xml (I
> >> >>believe
> >> >> > this should only add net new elements)
> >> >> >
> >> >> >         4. Call a modified parser.update_project that no longer
> >>makes
> >> >> > changes to
> >> >> > the platform config.xml
> >> >> >
> >> >> > I believe that this is complimentary with the approach Braden
> >> >>suggested
> >> >> > with one major change. I did not include plugin config munging on
> >>the
> >> >>app
> >> >> > config.xml. This is because I feel that by doing so we make the app
> >> >> > config.xml the same half build artifact half user edited mess we're
> >> >> trying
> >> >> > to solve. If the list disagrees with me I will of course implement
> >>it
> >> >>the
> >> >> > way Braden proposed it though.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 13-09-10 1:58 PM, "Jeffrey Heifetz" <jheifetz@blackberry.com>
> >> >>wrote:
> >> >> >
> >> >> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774
> >> >> > >
> >> >> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <tommy@devgeeks.org>
> >> >> wrote:
> >> >> > >
> >> >> > >>Then colour me excited!
> >> >> > >>
> >> >> > >>+1
> >> >> > >>
> >> >> > >>
> >> >> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <agrieve@chromium.org>
> >> >> wrote:
> >> >> > >>
> >> >> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams
> >> >> > >>><tommy@devgeeks.org>wrote:
> >> >> > >>>
> >> >> > >>>> I have been following this thread with a combination of
> >>interest
> >> >>and
> >> >> > >>>> trepidation.
> >> >> > >>>>
> >> >> > >>>> Interest:
> >> >> > >>>>
> >> >> > >>>> Anything that works towards ./platforms being a build
> >>artefact I
> >> >>am
> >> >> > >>>>all
> >> >> > >>>> for. In our app, ./platforms is already a build artefact. We
> >>used
> >> >> > >>>>hooks to
> >> >> > >>>> achieve this (updating config files, copying icon / splash
> >> >>assets,
> >> >> > >>>>etc).
> >> >> > >>>>
> >> >> > >>>> Just a quick questionŠ I know that ./platforms/../config.xml
> >> >>(even
> >> >> > >>>>after a
> >> >> > >>>> `cordova build Š`) still has the old defaults for name,
> >>author,
> >> >>id
> >> >> > >>>>etcŠ but
> >> >> > >>>> it doesn't seem to make any difference. We don't modify
> >> >> > >>>> ./platforms/../config.xml as it seemed like the modifications
> >>to
> >> >> > >>>> ./www/config.xml (and our custom hook modifications to say
> >> >> > >>>> ./platforms/android/AndroidManifest.xml) were sufficient.
> >> >> > >>>>
> >> >> > >>>> What am I missing wrt there being differences between these
> >> >>files?
> >> >> > >>>>
> >> >> > >>>> Trepidation:
> >> >> > >>>>
> >> >> > >>>> Users are just starting to get a handle on how the CLI works
> >> >>(though
> >> >> > >>>>there
> >> >> > >>>> are still some ongoing issues that I see fairly regularly,
> >>like
> >> >> > >>>>thinking
> >> >> > >>>> they still need to use Plugman directly even with CLI created
> >> >> > >>>>projects).
> >> >> > >>>> Just worried more workflow changes yet again are going to turn
> >> >> people
> >> >> > >>>>off
> >> >> > >>>> the CLI entirely. I may be a bit "twice shy", so if it's not
> >> >>going
> >> >> to
> >> >> > >>>> impact users much (except for making things much better) feel
> >> >>free
> >> >> to
> >> >> > >>>>set
> >> >> > >>>> me straight. hehe.
> >> >> > >>>>
> >> >> > >>>> - tommy
> >> >> > >>>>
> >> >> > >>> Some clarifications:
> >> >> > >>> - Change doesn't change workflow at all
> >> >> > >>> - Change will allow user's edits to their root config.xml
> >>actually
> >> >> work
> >> >> > >>>in
> >> >> > >>> all cases
> >> >> > >>>
> >> >> > >>> Win!
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> On 10/09/2013, at 2:57 AM, Michal Mocny <mmocny@chromium.org>
> >> >> wrote:
> >> >> > >>>>
> >> >> > >>>>> Aside from moving some files around and changing the order of
> >> >> > >>>>>operations
> >> >> > >>>> a
> >> >> > >>>>> bit, the biggest change will be adding support for <platform>
> >> >>and
> >> >> > >>>>> <config-file> to app.xml.  By the way, thats still called
> >> >> config.xml,
> >> >> > >>>>>do
> >> >> > >>>> we
> >> >> > >>>>> want to rename it to app.xml for 3.1?
> >> >> > >>>>>
> >> >> > >>>>>
> >> >> > >>>>> On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson
> >> >> > >>>>><braden@chromium.org
> >> >> > >>>>> wrote:
> >> >> > >>>>>
> >> >> > >>>>>> I should certainly be able to. I'm digging into a major
> >> >> refactoring
> >> >> > >>>>>>of
> >> >> > >>>>>> Plugman right now, though, so I'll probably want to finish
> >> >>that.
> >> >> If
> >> >> > >>>>>>it's
> >> >> > >>>>>> taking too long, though, then I'll switch gears and get
> >>this in
> >> >> > >>>>>>before
> >> >> > >>>> we
> >> >> > >>>>>> cut 3.1.
> >> >> > >>>>>>
> >> >> > >>>>>> Braden
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny <
> >> >> mmocny@chromium.org>
> >> >> > >>>> wrote:
> >> >> > >>>>>>
> >> >> > >>>>>>> Braden, are you going to be able to take this on this
> >>week?  I
> >> >> > >>>>>>>think it
> >> >> > >>>>>>> would make the upgrade from 3.0 much easier.
> >> >> > >>>>>>>
> >> >> > >>>>>>> -Michal
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>> On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny <
> >> >> mmocny@chromium.org>
> >> >> > >>>> wrote:
> >> >> > >>>>>>>
> >> >> > >>>>>>>> If you would use a different helloworld app template
> >>(which
> >> >>is
> >> >> now
> >> >> > >>>>>>>> possible to specify in both CLI and old workflow), then
> >>the
> >> >> > >>>>>>> pre-generatred
> >> >> > >>>>>>>> platform config.xml template would likely be the wrong
> >>one,
> >> >>and
> >> >> > >>>>>>>>thus
> >> >> > >>>>>>> this
> >> >> > >>>>>>>> bundling for self documentation would be a disservice.
> >> >> > >>>>>>>>
> >> >> > >>>>>>>> I don't see very much value in documentation for bundling
> >>the
> >> >> > >>>> config.xml
> >> >> > >>>>>>>> inside the platform template (when do we suspect users
> >>look
> >> >>at
> >> >> > >>>>>>>>that
> >> >> > >>>>>>> file,
> >> >> > >>>>>>>> as apposed to whats actually generated inside their
> >> >>project?).
> >> >> > >>>>>>>>Users
> >> >> > >>>>>>> can
> >> >> > >>>>>>>> read what is generated after adding a platform for their
> >> >> specific
> >> >> > >>>>>>>>app
> >> >> > >>>>>>> using
> >> >> > >>>>>>>> their chosen flow.
> >> >> > >>>>>>>>
> >> >> > >>>>>>>> I think that since bin/create can mush defaults.xml with
> >> >>app.xml
> >> >> > >>>>>>>>for
> >> >> > >>>>>>> both
> >> >> > >>>>>>>> flows, it should.
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>> On Mon, Sep 9, 2013 at 9:21 AM, Ian Clelland
> >> >> > >>>>>>>><iclelland@chromium.org
> >> >> > >>>>>>>> wrote:
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>> On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson <
> >> >> > >>>>>>> braden@chromium.org
> >> >> > >>>>>>>>>> wrote:
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>>> The defaults.xml is only part of the CLI workflow, yes.
> >>It
> >> >>has
> >> >> > >>>>>>>>>>no
> >> >> > >>>>>>>>> relevance
> >> >> > >>>>>>>>>> if you're not using CLI. BUT there is a complete
> >> >>config.xml in
> >> >> > >>>>>>>>>>the
> >> >> > >>>>>>>>>> bin/create template, and it can of course have the same
> >> >>values
> >> >> > >>>>>>>>>>as
> >> >> > >>>> you
> >> >> > >>>>>>>>> would
> >> >> > >>>>>>>>>> get from an unchanged CLI project (defaults.xml +
> >>app.xml).
> >> >> The
> >> >> > >>>>>>>>>> configuration values you get from the templates should
> >>be
> >> >>the
> >> >> > >>>>>>>>>>same
> >> >> > >>>> in
> >> >> > >>>>>>>>> both
> >> >> > >>>>>>>>>> cases, I agree completely.
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>> Yes, I think it's definitely achievable to have the
> >>complete
> >> >> > >>>>>>>>>template
> >> >> > >>>>>>>>> config.xml be exactly what you would get (modulo
> >>whitespace
> >> >>/
> >> >> > >>>> comments
> >> >> > >>>>>>> /
> >> >> > >>>>>>>>> etc) from installing the same sample app on the same
> >> >>platform
> >> >> > >>>>>>>>>with
> >> >> > >>>> CLI.
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>> If we can maintain that standard, then the various files
> >> >>become
> >> >> > >>>> almost
> >> >> > >>>>>>>>> self-documenting; its easy to look at the final
> >>config.xml
> >> >>file
> >> >> > >>>>>>>>>in
> >> >> > >>>> the
> >> >> > >>>>>>>>> template to see how the pieces should fit together, and
> >>work
> >> >> out
> >> >> > >>>> where
> >> >> > >>>>>>>>> each
> >> >> > >>>>>>>>> of the tags originally came from.
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>> It might be worth trying to generate the template
> >>config.xml
> >> >> > >>>>>>>>>*using*
> >> >> > >>>>>>> cli,
> >> >> > >>>>>>>>> just to maintain the correspondence between them.
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>> Ian
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>>> Braden
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>> On Sun, Sep 8, 2013 at 5:28 AM, James Jong
> >> >> > >>>>>>>>>><wjamesjong@gmail.com>
> >> >> > >>>>>>>>> wrote:
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>>> Andrew - what I was thinking was pretty much what
> >>Michal
> >> >> wrote
> >> >> > >>>>>>> below.
> >> >> > >>>>>>>>>>> Perhaps it was my interpretation of the original note
> >>but
> >> >>I
> >> >> > >>>>>>> thought
> >> >> > >>>>>>>>>>> defaults was to be applied only in the CLI workflow.
> >> >> > >>>>>>>>>>>
> >> >> > >>>>>>>>>>> -James Jong
> >> >> > >>>>>>>>>>>
> >> >> > >>>>>>>>>>> On Sep 7, 2013, at 1:05 PM, Michal Mocny <
> >> >> mmocny@chromium.org>
> >> >> > >>>>>>> wrote:
> >> >> > >>>>>>>>>>>
> >> >> > >>>>>>>>>>>> With this proposal as it stands, I think that is
> >>already
> >> >> true
> >> >> > >>>>>>>>>>>>(at
> >> >> > >>>>>>>>> least
> >> >> > >>>>>>>>>>> for
> >> >> > >>>>>>>>>>>> the initial contents, obviously user can make edits
> >> >>later).
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>> Ie, defaults.xml + app.xml = initial config.xml for
> >>both
> >> >> > >>>>>>>>>>>>cases,
> >> >> > >>>>>>>>> which
> >> >> > >>>>>>>>>> use
> >> >> > >>>>>>>>>>>> the same helloworld template's app.xml.
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>> If there are specific differences to the default
> >>values
> >> >>that
> >> >> > >>>>>>>>>>>>we
> >> >> > >>>>>>>>> want,
> >> >> > >>>>>>>>>> we
> >> >> > >>>>>>>>>>>> maybe will want to use a different app.xml for each,
> >>but
> >> >> > >>>>>>>>> defaults.xml
> >> >> > >>>>>>>>>>>> should be tied to a platform-version not to a
> >>workflow.
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>> -Michal
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>> On Sat, Sep 7, 2013 at 7:56 AM, Andrew Grieve <
> >> >> > >>>>>>> agrieve@chromium.org
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>> James - that's a nice goal, but I don't think it's
> >> >> feasible.
> >> >> > >>>>>>>>>>>>>Did
> >> >> > >>>>>>>>> you
> >> >> > >>>>>>>>>>> have a
> >> >> > >>>>>>>>>>>>> way to do that in mind?
> >> >> > >>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>> On Fri, Sep 6, 2013 at 10:31 PM, James Jong <
> >> >> > >>>>>>> wjamesjong@gmail.com>
> >> >> > >>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>> I would like to see the defaults be applied in all
> >> >>cases.
> >> >> > >>>>>>>>>>>>>>For
> >> >> > >>>>>>>>>>>>>> consistency, less confusion, and easier
> >>documentation.
> >> >> If
> >> >> > >>>>>>>>>>>>>>we
> >> >> > >>>>>>> add
> >> >> > >>>>>>>>> or
> >> >> > >>>>>>>>>>>>> change
> >> >> > >>>>>>>>>>>>>> the defaults in a release, both workflows should get
> >> >>it.
> >> >>  In
> >> >> > >>>>>>>>>>>>>>my
> >> >> > >>>>>>>>> mind,
> >> >> > >>>>>>>>>>> the
> >> >> > >>>>>>>>>>>>>> CLI platform config.xml should be equivalent to the
> >> >> > >>>>>>>>>>>>>>bin/create
> >> >> > >>>>>>>>> one.
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>> -James Jong
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>> On Sep 6, 2013, at 11:06 AM, Michal Mocny
> >> >> > >>>>>>>>>>>>>><mmocny@chromium.org
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>> I thought we were adding support for the last bit
> >>(ie,
> >> >> app
> >> >> > >>>>>>>>> generic
> >> >> > >>>>>>>>>> not
> >> >> > >>>>>>>>>>>>>>> platform specific preferences) to "app.xml" which
> >>the
> >> >> > >>>>>>> helloworld
> >> >> > >>>>>>>>>>>>> template
> >> >> > >>>>>>>>>>>>>>> should ship with and bin/create should apply.
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>> -Michal
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>> On Fri, Sep 6, 2013 at 10:52 AM, Ian Clelland <
> >> >> > >>>>>>>>>> iclelland@chromium.org
> >> >> > >>>>>>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> The template version needs to be a complete config
> >> >>file
> >> >> > >>>>>>>>>>>>>>>>for
> >> >> > >>>>>>> the
> >> >> > >>>>>>>>>>> sample
> >> >> > >>>>>>>>>>>>>> app,
> >> >> > >>>>>>>>>>>>>>>> though. You should be able to run bin/create and
> >>then
> >> >> > >>>>>>>>>>>>>>>>build
> >> >> > >>>>>>> the
> >> >> > >>>>>>>>>>> Hello,
> >> >> > >>>>>>>>>>>>>>>> Cordova app immediately.
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> defaults.xml is supposed to be stripped right
> >>down to
> >> >> just
> >> >> > >>>>>>> the
> >> >> > >>>>>>>>>>>>>>>> platform-specific options which, in theory,
> >>shouldn't
> >> >> need
> >> >> > >>>>>>> to be
> >> >> > >>>>>>>>>>>>>> specified
> >> >> > >>>>>>>>>>>>>>>> by every app.
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> At least that's how it works in my head :) The
> >> >> distinction
> >> >> > >>>>>>> may
> >> >> > >>>>>>>>> be
> >> >> > >>>>>>>>>>> less
> >> >> > >>>>>>>>>>>>>>>> important than I'm imagining.
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> Ian
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> On Fri, Sep 6, 2013 at 9:08 AM, Michal Mocny <
> >> >> > >>>>>>>>> mmocny@chromium.org>
> >> >> > >>>>>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>> If the content or format of defaults.xml and the
> >> >> initial
> >> >> > >>>>>>>>>> config.xml
> >> >> > >>>>>>>>>>>>>> will
> >> >> > >>>>>>>>>>>>>>>> be
> >> >> > >>>>>>>>>>>>>>>>> different then we should ship both -- but I don't
> >> >>think
> >> >> > >>>>>>>>>>>>>>>>>they
> >> >> > >>>>>>>>> will
> >> >> > >>>>>>>>>>> be,
> >> >> > >>>>>>>>>>>>>> so
> >> >> > >>>>>>>>>>>>>>>> I
> >> >> > >>>>>>>>>>>>>>>>> think we just ship the template with a defaults
> >> >>file.
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>> -Michal
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 11:19 PM, Ian Clelland <
> >> >> > >>>>>>>>>>>>> iclelland@chromium.org
> >> >> > >>>>>>>>>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 5:16 PM, James Jong <
> >> >> > >>>>>>>>> wjamesjong@gmail.com
> >> >> > >>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>> defaults.xml - Is that only used by CLI?  And
> >>not
> >> >> used
> >> >> > >>>>>>>>>>>>>>>>>>>by
> >> >> > >>>>>>>>>>>>> bin/create
> >> >> > >>>>>>>>>>>>>>>>>>> scripts?
> >> >> > >>>>>>>>>>>>>>>>>>> It was bit unclear to me from the description
> >> >>since
> >> >> > >>>>>>>>>>>>>>>>>>>both
> >> >> > >>>>>>> were
> >> >> > >>>>>>>>>>>>>>>> mentioned
> >> >> > >>>>>>>>>>>>>>>>>>> regarding the 2 xml files.
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>> Yes, that's the idea. If you're using the
> >> >>bin/create
> >> >> > >>>>>>> scripts,
> >> >> > >>>>>>>>>> then
> >> >> > >>>>>>>>>>>>>>>> there
> >> >> > >>>>>>>>>>>>>>>>> is
> >> >> > >>>>>>>>>>>>>>>>>> a complete "config.xml" file in the template
> >>that
> >> >>will
> >> >> > >>>>>>>>>>>>>>>>>>be
> >> >> > >>>>>>> used
> >> >> > >>>>>>>>>> for
> >> >> > >>>>>>>>>>>>>> your
> >> >> > >>>>>>>>>>>>>>>>> new
> >> >> > >>>>>>>>>>>>>>>>>> app. This is for strict backwards compatibility
> >> >>with
> >> >> > >>>>>>> anyone's
> >> >> > >>>>>>>>>>>>> workflow
> >> >> > >>>>>>>>>>>>>>>>> that
> >> >> > >>>>>>>>>>>>>>>>>> doesn't currently include CLI.
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>> If you are using CLI, then we will construct a
> >>new
> >> >> > >>>>>>> config.xml
> >> >> > >>>>>>>>>> file
> >> >> > >>>>>>>>>>>>> for
> >> >> > >>>>>>>>>>>>>>>>> you
> >> >> > >>>>>>>>>>>>>>>>>> instead, from three sources: defaults.xml, which
> >> >> > >>>>>>>>>>>>>>>>>>specifies
> >> >> > >>>>>>>>> all of
> >> >> > >>>>>>>>>>>>> the
> >> >> > >>>>>>>>>>>>>>>>>> platform defaults; the various plugin.xml files,
> >> >>and
> >> >> > >>>>>>>>>>>>>>>>>>your
> >> >> > >>>>>>>>> app's
> >> >> > >>>>>>>>>>>>>>>>> config.xml
> >> >> > >>>>>>>>>>>>>>>>>> file. The end-result should be the same, but you
> >> >>have
> >> >> a
> >> >> > >>>>>>> clear
> >> >> > >>>>>>>>>> place
> >> >> > >>>>>>>>>>>>> to
> >> >> > >>>>>>>>>>>>>>>>>> override the defaults for your app that lives
> >> >>outside
> >> >> of
> >> >> > >>>>>>> your
> >> >> > >>>>>>>>>>>>>> platforms
> >> >> > >>>>>>>>>>>>>>>>>> directory, and the cordova team has a clear
> >>place
> >> >>to
> >> >> set
> >> >> > >>>>>>> those
> >> >> > >>>>>>>>>> same
> >> >> > >>>>>>>>>>>>>>>>>> defaults.
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>> Ian
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>> The new CLI prepare flow makes sense to me.
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>> -James Jong
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>> On Sep 5, 2013, at 2:21 PM, Michal Mocny <
> >> >> > >>>>>>>>> mmocny@chromium.org>
> >> >> > >>>>>>>>>>>>>>>> wrote:
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>> 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.xml
> >> >> > >>>>>>>>>>>>>>>>>>>>> should live? (Maybe it doesn't have to exist
> >>and
> >> >> > >>>>>>> defaults
> >> >> > >>>>>>>>> can
> >> >> > >>>>>>>>>>>>> just
> >> >> > >>>>>>>>>>>>>>>>> be
> >> >> > >>>>>>>>>>>>>>>>>>> vars
> >> >> > >>>>>>>>>>>>>>>>>>>>> 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
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>> -
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>> ³platform config.xml² refers to the
> >> >> > platform-specific
> >> >> > >>>>>>>>>>>>>>>> config.xml
> >> >> > >>>>>>>>>>>>>>>>>>>>> files,
> >> >> > >>>>>>>>>>>>>>>>>>>>>> eg. platforms/android/res/xml/config.xml.
> >>This
> >> >>is
> >> >> > the
> >> >> > >>>>>>>>> final
> >> >> > >>>>>>>>>>>>>>>> file
> >> >> > >>>>>>>>>>>>>>>>>> read
> >> >> > >>>>>>>>>>>>>>>>>>>>> by
> >> >> > >>>>>>>>>>>>>>>>>>>>>> Cordova at runtime.
> >> >> > >>>>>>>>>>>>>>>>>>>>>> -
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>> ³app config.xml² 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
> >> >> > >>>>>>>>>>>>>>>>>>> and
> >> >> > >>>>>>>>>>>>>>>>>>>>>> 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
> >> >> > >>>>>>>>>>>>>>>>>>> the
> >> >> > >>>>>>>>>>>>>>>>>>>>>> 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.
> >> >> > >>>>>>>>>>>>>>>>>> Less
> >> >> > >>>>>>>>>>>>>>>>>>>>>> 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
> >> >> > >>>>>>>>>>>>>>>>>>> unchanged
> >> >> > >>>>>>>>>>>>>>>>>>>>>>  for people who are not using CLI. Plugman
> >> >>still
> >> >> > >>>>>>> munges
> >> >> > >>>>>>>>>> this
> >> >> > >>>>>>>>>>>>>>>>> file
> >> >> > >>>>>>>>>>>>>>>>>>>>> and
> >> >> > >>>>>>>>>>>>>>>>>>>>>>  outputs back to it, same as now.
> >> >> > >>>>>>>>>>>>>>>>>>>>>>  -
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>> Second, adjust the CLI¹s cordova create
> >> >>template
> >> >> so
> >> >> > >>>>>>> that
> >> >> > >>>>>>>>> its
> >> >> > >>>>>>>>>>>>>>>>>>> top-level
> >> >> > >>>>>>>>>>>>>>>>>>>>>> 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¹s
> >> >>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¹t be
> >> >> needlessly
> >> >> > >>>>>>>>> setting
> >> >> > >>>>>>>>>>>>>>>>>>> defaults
> >> >> > >>>>>>>>>>>>>>>>>>>>>>     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
> >> >> > >>>>>>>>>>>>>>>>>> in
> >> >> > >>>>>>>>>>>>>>>>>>>>>> the
> >> >> > >>>>>>>>>>>>>>>>>>>>>>  config.
> >> >> > >>>>>>>>>>>>>>>>>>>>>>  -
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>>  In particular, it can have <config-file>
> >>tags
> >> >>in
> >> >> > the
> >> >> > >>>>>>>>> usual
> >> >> > >>>>>>>>>>>>>>>>>> format
> >> >> > >>>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>>>
> >> >> > >>>>>>>>>>>
> >> >> > >>>>>>>>>>>
> >> >> > >>>>>>>>>>
> >> >> > >>>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> >
> >>>---------------------------------------------------------------------
> >> >> > >This transmission (including any attachments) may contain
> >> >>confidential
> >> >> > >information, privileged material (including material protected by
> >>the
> >> >> > >solicitor-client or other applicable privileges), or constitute
> >> >> > >non-public information. Any use of this information by anyone
> >>other
> >> >>than
> >> >> > >the intended recipient is prohibited. If you have received this
> >> >> > >transmission in error, please immediately reply to the sender and
> >> >>delete
> >> >> > >this information from your system. Use, dissemination,
> >>distribution,
> >> >>or
> >> >> > >reproduction of this transmission by unintended recipients is not
> >> >> > >authorized and may be unlawful.
> >> >> >
> >> >> >
> >> >> >
> >>---------------------------------------------------------------------
> >> >> > This transmission (including any attachments) may contain
> >>confidential
> >> >> > information, privileged material (including material protected by
> >>the
> >> >> > solicitor-client or other applicable privileges), or constitute
> >> >> non-public
> >> >> > information. Any use of this information by anyone other than the
> >> >> intended
> >> >> > recipient is prohibited. If you have received this transmission in
> >> >>error,
> >> >> > please immediately reply to the sender and delete this information
> >> >>from
> >> >> > your system. Use, dissemination, distribution, or reproduction of
> >>this
> >> >> > transmission by unintended recipients is not authorized and may be
> >> >> unlawful.
> >> >> >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> This transmission (including any attachments) may contain confidential
> >> information, privileged material (including material protected by the
> >> solicitor-client or other applicable privileges), or constitute
> >>non-public
> >> information. Any use of this information by anyone other than the
> >>intended
> >> recipient is prohibited. If you have received this transmission in
> >>error,
> >> please immediately reply to the sender and delete this information from
> >> your system. Use, dissemination, distribution, or reproduction of this
> >> transmission by unintended recipients is not authorized and may be
> >>unlawful.
> >>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message