Re: Conf: argue !

Wim Niemans ri wrote:
> The discussion that followed showed two opinions:
> 1. preloading using files
> 2. exclusive db_access.
> 
> Now caching comes into discussion. I'm lost on the intended use of conf.

The idea is simply that reading all confs from db can be very long, and 
it'sll be done from many parts of the code, for each page requested.
Whereas including a php file caching all confs is easy and probably 
fast. Db is useful to maintain the list of values and have a gui to edit 
them.

> I mean, to have code for both opinions is easy. Stronger, it would allow 
> for custom code to access f.i. dbase_files (isn't that berkeley db?).
> It's an option to let users code such thing. By design, that is.

Why not.

> Why would we translate and cache conf: on the fly *and* cache the config ?

See above: because reading db on the fly can be costly.

> There is the egg-chicken problem. Conf: needs a configuration when it is 
> db_based. Is there an elegant solution for this?

Yes, build.properties. Or a reserved name and an xml conf: conf first 
reads conf/Conf.xml then is able to read conf from db.

-- 
Jean-Christophe Michel