On 12/22/2010 03:26 PM, Øystein Torget wrote:
Det som jeg kunne ønsket var en type konfigurasjon à la Apache, hvor du
har en master konfigurasjonsfil som inneholder defaults og ting som
aldri endrer seg, og så lastes det etterpå inn site-spesifikke filer med
direktiver som overstyrer de som ble definert i hovedfilen. På den
måten ville filene for hver enkelt applikasjon bli redusert ganske
dramatisk.
Jeg støtter den. Det hadde vært veldig praktisk. Så vidt jeg husker fant Geir også en CPAN modul som støtter mer eller mindre det vi har fra før + denne muligheten. Var det Config::General eller noe slikt?
Jepp. Config::General bruker samme syntax og kan lese Apache-config 100%. Det innebærer at den bl.a. støtter følgende vi mangler i dag:
- seksjoner og hierarkier, slik at ting blir gruppert logisk
- blir lettere å diffe/finne igjen direktiver
- overriding, så man kan sette defaults som overstyres per app
- inkludering av andre filer, så hver app/site kun trenger å spesifisere det som er spesielt for denne
- mulighet for å deklarere hash-strukturer som verdier, ikke bare strenger
- (kjekt for coastlines i WMS, hvor jeg trenger å spesifisere ett kart for hver projeksjon)
- sannsynligvis mulighet for en slags validering, selv om det ikke finnes noe schemaspråk
I tillegg har den som i dag here-documents, deklarering av variable som kan brukes i senere direktiver (à la [==xxx==], dog riktignok one-pass) etc.
Dette kan naturligvis ikke brukes fra annet enn Perl, men når PHP-delen er faset ut burde det være mulig å lage et Perlscript som trekker ut nødvendig info og genererer en defaults-fil som kan sources fra shellscripts.
http://search.cpan.org/~tlinden/Config-General-2.50/General.pm
Discussion
Let's move this into a discussion, and switch to enlish on this WIKI. Just to repeat:
Configuration similar to Apache, where it is possible to have general metamod-options, which can be overwritten by the metamod-instances.
Config::General can read apache-config to 100%. It support all apache-stuff + many other things.
Config::General is perl only.
And now my answer:
This sounds very good, but if we switch to another config-system, I will not switch to a perl-library, but rather to a configuration-specification. We might internally use Config::General, but the specification should be 100% apache-config without extensions.
We haven't decided if we phase out all of the php-code (OAI-PMH will be php for a while, I guess). We don't know when we have to include other languages (pyWPS?). It will be easier to find a parser for a accepted configuration specification, than to translate a library.
The plain Apache format has hierarchies, inclusions and overriding. On the other hand it lacks variables, complex values nor here-documents, which I fail to see how we could do without. As an example, APP_MENU would be a real pain to write.
Config::General does indeed have a spec. What it lacks is multiple parser implementations. This would be an issue when not using Perl. However, having a standardized format is not much help unless there exists a parser for it (writing your own parser is time-consuming, error-prone and reinventing the wheel).
After Perl our most used language is Bash, which has no parsing capability except for environment variables. Thus we need to write a Perl script which translates the required config variables into shell declarations. If we can do this for Bash, we can also do it for PHP. If we standardize on the full Config::General format we can easily generate YAML or JSON from it, but not the other way around..
What we still need is validation. But without a formal schema language we will have to implement that manually anyhow.