Re: Conf: argue !

>  - Factory defaults are always read from the module's directory in the 
> repository and stored as XML. No changing here.

Ok, agree.

>  - We force the user to have a binarycloud.conf.xml file that contains 
> basic configuration for the framework and a Datasources.conf.xml 
> because otherwise he might run into problems with getting the 
> configuration.

I like this much.

>  - The user might *either* store a given domain in a conf.xml file 
> *or* in a database. That should stop a lot of problematic points I see 
> with wild mixture.

Yes, this is an absolute necessity.

> All configuration files are stored flat in conf/ because we forbid to 
> have modules with the same name as core modules in vortex. The 
> configuration files have to have the same name as the modules they are 
> defined in. The module name is the domain name.

Ah, yes, simplicity :)


> - All conf/ configuration is read at system startup and cached. Same 
> for the database.

If cached, this is cool w/ me

> - We do not support XML writing for now, so editeable stuff should go 
> into the database.

Yes. In fact I would argue that XML writing is a very bad idea.

> - If something in the database is changed, we update this in the cache.

Ok.

> - We provide a phing target "clear-conf" that clears the configuration 
> cache and forces the system to read the configuration anew.

Ok.

> - Additionally, we have a "force recompile" and "check valid cache" 
> setting like smarty, so we do not have fmtime() calls in a production 
> system because they are slow like hell.

Agree.

> - If any of the rules like "domain name equals configuration file 
> name", "conf.xml and db domain" etc. are violated, we halt the whole 
> system. Errorneus configuration could screw up everything.

Yep. We should have a series of tests which can be performed by phing 
as pre-promote checks. I would also VERY MUCH like to have a 
sophisticated set of "live promote" phing buildfiles.

> - Every configuration domain - may it be database or conf.xml must 
> provide a "for-version" property that holds the *module's* version so 
> automatic update scripts are easy to provide.

Agree. Versions should not be a range - if you are trying to use 2.0 
conf with a 3.0 app, the app should receive no values from conf and 
throw its own exception.

> - Of course we provide migration scripts when the configuration format 
> changes. That is BC specific, however. Consider the next point for 
> module version specific changes:

Right.

> - We provide templates for configuration migration scripts. For XML we 
> provide xslt templates, for the database, we provide PHP Phing Tasks 
> that do SQL queries.

Yep.

> - Conf is a central server and delegates the reading/storing to 
> ConfDriver classes, one for each data type.
> - Conf cares about configuration caching and validating the cache 
> depending on the settings described above.
> - Conf also cares about "query caching", i.e. the tree caching. This 
> does not have to go to another class IMO. It is simpler when 
> centralized and objects are pretty expensive in PHP ;)

This must be generalized - i.e. query caching is a common thing that is 
useful in lots of places.


> - We store
>   * strings as strings, fully translateable
>   * booleans are stored as chars 'Y' or 'N' (fast)
>   * integers are stored as integers
>   * floats are stored as floats
>   * no "raw" data
>
> This way the data is completely queryable.
>
> What did you propose for the configuration schema? I'd propose:
>
>   domain   := (id, description)
>   property := (id, path, domain, content, description)

> domain::id and setting::id are primary keys, setting::id is numeric, 
> domain::id is a short, english string value (max 20 chars) and the 
> module name. domain::description and setting::description is a 
> '#translateable string#'.

where is setting?

> Conf would care about uniqueness of string description ids within a 
> certain domain. The translation of a configuration description string 
> would go into a module's translation Strings.en.xml (or later DB).

I would prefer that we NEVER store translations in XML - I think this 
system should start properly in a DB and stay there.

> Trees are pretty sucky in SQL (because of its inferior implementation 
> of the relational model). I thus agree to storing full paths and to 
> extraction in PHP. We will cache all this anyway so it is not that 
> expensive in production:

Trees aren't that hard, but I agree that in this case they seem 
excessive.

(Though I would like a proper tree model for NDFs... but I'm working on 
a proposal along those lines, not ready yet).

>   /domain1/value             value
>   /domain1/path/to/value     value2
>   /domain1/path/to/another   foobar
>
> Which would become:
>
>   array(
>     'value' => 'value',
>     'path' => array(
>       'to' => array(
>         'value' => 'value2',
>         'another' => 'foobar',
>       ),
>   )

Right.

_a