Hello gang:
The next step in the process of removing the dependency on WML is to
replace the config.wml configuration technique we've been using so
far. Here is a brief outline of a schema I've been thinking about.
1. We introduce a config.xml file resembling the WML original, of
the form like:
!-- ** SMTP SERVER CONFIGURATION * --
!--
CFG_MISCUTIL_SMTP_PORT: define which port to use on the
outgoing mail server defined in the previous step. (example:
25)
--
CFG_MISCUTIL_SMTP_PORT25/CFG_MISCUTIL_SMTP_PORT
and we let admins customize this config.xml file. It will closely
resemble config.wml, hence no big change. It will also resemble
Indico's config.xml way of doing things, which is good for the CDS
software house commonality for admins having both Indico and
Invenio installed. (We won't use Indico's hidden default
parameters though.)
2. The autotools-generated variables, such as the location of the
pdftotext auxiliary program, will still be generated automatically
during configure-time and stored in some read-only configbis.xml
independently.
3. During build-time, we shall generate config.py that will be
identical to what we have now. It will be constructed out of both
config.xml and configbis.xml. The Invenio codebase can therefore
still do things like from invenio.config import CFG_FOO. No
changes are necessary here.
4. Both config.xml and configbis.xml will be installed into
/opt/cds-invenio/etc place somewhere, so that admins could edit
them anytime during runtime in order to change some configuration
parameter. They would then launch a new command tool such as:
$ inveniocfg --update-config
that will take their newly edited config.xml and update config.py.
As a result, there will be no more need to keep Invenio sources
hanging around on the disk after the initial Invenio installation
of the demo site.
5. When upgrading from one Invenio release to another, admins would
run a command like:
$ inveniocfg --upgrade-config
that would try to automatically merge newly distributed demo
config.xml with their current, locally modified config.py. The
upgrade tool would merge silently what can be merged silently, and
would prompt admins for an action in cases such as (a) a config
variable made obsoleted or (b) a config variable changed its
default value in between Invenio releases.
6. As for the format of the config.xml itself:
a) The config.xml file could be a standalone editable file in a
simple format described above, always containing latest
customized values of users, such as:
!-- ** SMTP SERVER CONFIGURATION *** --
!--
CFG_MISCUTIL_SMTP_PORT: define which port to use on the
outgoing mail server defined in the previous step.
(example: 25)
--
CFG_MISCUTIL_SMTP_PORT/CFG_MISCUTIL_SMTP_PORT
The original Invenio installation would probably install
original files of the form config.xml_default_0.92.1 for
future reference, if admins want to change their config
parameters later during runtime without having to consult the
sources.
b) The config.xml could possibly contain separate spaces for
default and custom values, such as:
invenio-config-param
name=CFG_MISCUTIL_SMTP_PORT
default-value=25
custom-value=
help=Defines which port ...
so that admins would have to add custom-value=... lines to
every parameter they would like to customize. Or we could
have some ithaca.../ithaca conditionals to denote sections
overriding default values for a particular Ithaca
installation, thus keeping one config file for X sites admin
may maintain (DEV, TEST, PROD).
c) Pushing the b) model further, we could have one generic
config.xml file, and one custom config_ithaca.xml file
where the admins would put only their custom changes, e.g.
CFG_MISCUTIL_SMTP_PORT/CFG_MISCUTIL_SMTP_PORT
The system would take CFG_FOO parameter from this local file,
if it exists there, otherwise from the default file.
This resembles a bit the technique we currently use for the
style template skins, e.g. (big) webstyle_templates.py file
and (small) webstyle_templates_ithaca.py file that only
overwrites what has to be overwritten. Thus admins would
basically have to maintain smaller diff files against the
distributed config files.
(BTW, we plan to enlarge the template skin technique to other
Invenio config files, e.g. HB.bfo (default) versus HB_ithaca.bfo
(customized), or wrd.cfg (default) versus wrd_ithaca.cfg
(customized). This will
