Re: Conf: argue !

Manuel Holtgrewe wrote:

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

They'll have to put their conf values in xml and call 
tools/cli/reload-confs.php instead of tools/web/reload-confs.php :-)


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

Why do you think serialize is better ? isn't it slower to read 
serialized arrays than to parse a php file?

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

Excaty, so i wonder when these extra caching options will be useful :p
dev time: reload always; prod: never reload;

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

Are you telling reading mtime of files is slow?
Why is it hard to select all conf and write it down as php? (same with 
xml by the way, since we need to handle precedence of custom over 
default values). And using Creole could do it with other dbs, isn't it?

>>> - 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 mean that we can check bad names in conf when rebuilding the cache.
No need to wait for running the site.

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

Very complex imo. And we won't be able to use conf for translation, 
since translation must work before conf is parsed ;p
Raw is good, or we need to add a simple way to tell "replace this php 
constant by its value at runtime".


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

Right, but there's no relation (nowhere referencing this path in other 
confs) so changing path doesn't hurt anything.

-- 
Jean-Christophe Michel