Item11836: Different way to store configure data

Now configure stores configuration data as perl-script. This is hard to manage and AFAIK it is loaded with require. This causing the need reload server under Modperl (and PSGI) environment.

Would be much better (and IMO easier manageable) when the configuration was in the YAML file. YAML is widely accepted and well-known format, easily editable with different sw tools (or with simple vi). Alternatively, JSON or XML. The main point is - reloadable configurations without server restart.

As another enhancement, the development (testing) installation should check the load-time and the last modification time of the config.yaml, so the engine can reload the config when it is changed - without sever restart. (this can be done with some OS file-change-notification support too.)

-- JozefMojzis - 08 May 2012

I like that. How about making this a proper FeatureProposal?

-- MichaelDaum - 08 May 2012

Agreed. This needs a feature proposal, but is indeed worth considering. We have another difficult problem in configure that this might help address. Configure does a merge of each Extension Config.spec file into the LocalSite.cfg, but it happens silently, with no indication that the new default values were added. It was decided that it is too costly for core to do this for every transaction. The side effect is that installing an extension that has "no apparent configuration" still requires that configure be run, and some bogus change be saved, or the merge doesn't happen. It's the source of one of the "Foswiki mysteries". ... I ran configure and suddenly blah started working but it didn't change anything

-- GeorgeClark - 08 May 2012

I'm not wedded to the existing format, but I don't see the point of changing to YAML without a good reason. AFAICT the only positive of a move to YAML would be to access third-party editing tools. It has no other advantage.

Foswiki configuration has two parts to it, the configuration spec and the configuration data. The configuration spec is built up by parsing comments from Foswiki.spec + the Config.spec's from the installed extensions (slow). The configuration data is stored in LocalSite.cfg and is read using require (very fast). A normal script = view, edit, whaetever - loads the configuration data, but does not load the spec. configure loads the spec, and uses it to populate the configuration data with any missing entries from recently installed extensions. Changing the store format of the configuration data doesn't change any of this, it still has to be done the same way - the spec and the data have to be kept apart.

To address Jozef's point about reloadable configuration; there is no reason not to reload the existing Perl LocalSite.cfg on change. It just requires someone to write the code. There is no need to change the store format.

To address George's point. Foswiki::Configure::Load::readConfig already supports a $config_spec flag that loads the Config.spec for any plugin or contrib found on the @INC path. This could easily be modified to load Config.spec only for any module that does not already have an entry in $Foswiki::cfg. Of course that won't do everything configure does, because it won't read the spec, just the default configuration values, but it will provide a suitable default for every setting that has an uncommented entry in the Config.spec.

-- Main.CrawfordCurrie - 08 May 2017 - 08:40

Commenting is disabled while not logged in