Re: Conf: argue !

Manuel Holtgrewe wrote:
>  - Factory defaults are always read from the module's directory in the 
> repository and stored as XML. No changing here.
>  - 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.
>  - 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.

I'd propose to be simpler: xml conf would be used _only_ for default 
conf files stored in packages (core or vortex). Xml would be loaded into 
  db via the web interface vortex/confadmin.
All dev values would go into db. Eventually user prefs would go into db 
using the same schema.

> 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.

Agree.

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

How ? I'd propose to use a var_dump of all confs and simply include this 
php file. It would be regenerated on each change in confadmin.

> - We do not support XML writing for now, so editeable stuff should go 
> into the database.
> - If something in the database is changed, we update this in the cache.

Exactly.

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

Same idea but via web admin.

> - 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.

Simpler = no valid cache testing at all, simply regenerate the cache 
when data changed or when a reload-from-xml action is done.

> - 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.

Easier to check in a reload-from-xml-into-db.

> I'd propose the following:
> 
> - 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

Ah. But how to use path with constants like BC_BASE_URL without raw type?

> 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#'.

property::path should already be unique. Of course this makes a long 
pkey, but since all db is cached into a php array, why have a numeric id?

-- 
Jean-Christophe Michel