Re: Conf: argue !

On 24 Feb 2005 at 18:45, Jean-Christophe Michel wrote:

> Manuel Holtgrewe wrote:
> 
> > 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 :-)

So, the proposed method myConf->set(path,value) shoud evaporate than?

Having an install script for a conf is a good idea. Same goes for 
translated language packs.

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

From a previous message on this list:

> Ugh - no serialized data in a DB please. Cache to be fast, but use nice
> types that are not language specific.

Is this serious?

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

Agree totally.

> I mean that we can check bad names in conf when rebuilding the cache.
> No need to wait for running the site.

Check for bad names? What's the definition of a 'bad name' ?
To my humble opnion conf can't check nothing while loading.

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

You will need an 'id' when updating, since you can't guarantee that a path 
is unique. Stronger, a unique integer-id is required.

wim niemans