cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <to...@devgeeks.org>
Subject Re: config.xml as a build artifact for less suffering and easier upgrades
Date Mon, 09 Sep 2013 23:37:33 GMT
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





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


Mime
View raw message