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_PORT>25</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>9999</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="9999"
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>9999</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 permit admins to make several "make
install" operations without overriding their custom edits. This
technique would of course work with the model 6a too.)
7. The "inveniocfg" tool could evolve in the future to have options
such as "--load" and --dump" for configurations that are stored in
the database. This will enable admins to dump from, edit, and load
back to database various modules' configurations, such as:
$ inveniocfg --dump websearch-config > websearch-config.xml
$ emacs websearch-config.xml
$ inveniocfg --load websearch-config < websearch-config.xml
without having to use the WebSearch Admin web interface it all.
This will also enable one to quickly replicate some modules' setup
on another Invenio instance.
(BTW, Greg has a basic WebAccess loader/dumper ready, so we should
be able to start committing something visible soon.)
8. Getting rid of WML will enable us to rethink the whole building
process later. E.g. we could imagine phasing out autotools for
setup.py or for tools like SCons. With the installation process
not having to know anything about CDSNAME, DBPASS, page headers and
friends, it will be a snap to create and distribute DEBs or RPMs.
But this is not for today, it will come later.
Please tell me what you think about this and what config.xml format
would you prefer. At this moment, I guess I like a simple 6a/6c
schema, but I'll keep brainstorming in the meantime too... These were
just my preliminary thoughts on the subject.
Best regards
--
Tibor Simko ** CERN Document Server ** <http://cds.cern.ch/>
