Re: Conf: argue !

Jean-Christophe Michel schrieb:
> 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.

I like the idea of "core settings cannot be changed on the fly"... And 
what about people who do not have a database?

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

Yes, this is what I meant, but I'd use serialize(). However, things 
could be changed through some sqlite tool and you'd have to check for 
that kind of changes.

Extra caching options don't hurt: In development, you read configuration 
every time and in production, you have full caching.


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

Hard to do if people change things with another database tool or edit 
the XML configuration.

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

Yes, but this happens before caching, so people cannot even create 
invalid configuration with real DB access.

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

Good point. We could make configuration values "translateable" and 
support @TOKEN@ style tokens.

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

Because you might decide to shift things and path is volatile in this 
respect. However, you are right, id is a candidate key - a *possible* key.


Manuel