Item11836: Different way to store configure data

pencil
Priority: Enhancement
Current State: Proposal Required
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: Configure
Branches:
Reported By: JozefMojzis
Waiting For:
Last Change By: CrawfordCurrie
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

 

ItemTemplate edit

Summary Different way to store configure data
ReportedBy JozefMojzis
Codebase 1.1.5, trunk
SVN Range
AppliesTo Engine
Component Configure
Priority Enhancement
CurrentState Proposal Required
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release02x01Checkins
Release02x00Checkins
Release01x01Checkins
Topic revision: r4 - 08 May 2017, CrawfordCurrie - This page was cached on 16 Jan 2020 - 02:14.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy