Re: Conf: argue !

On 24 Feb 2005 at 13:41, alex black wrote:

> guys -
> 
> these suggestions all needs to be integrated into a revised conf 
> proposal draft on the wiki - once we have all the points in front of us 
> in a draft we agree on, each of the points should be put in a ticket, 
> then we can get to hacking.

From previous messages:

>Finally, I'm thinking of loading a config and when the loading is 
>completed, having that object written (once) somewhere in a serialized 
>format. That could be a db or a disk file. Than there is only a need for 
>one atomic action to load the complete config, ignoring the 'raw' 
>formats.
>Ofcourse, there is a need to adjust the config in a nice admin interface.
>This interface could list the shipped configs along with the current 
>settings, adjust them and serialize it again to disk and/or db.
>This mechanism brings some nice features; amongst them speed, security 
>and 
>makes (possible) upgrading a controlled effort.

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.

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 would we translate and cache conf: on the fly *and* cache the config ?

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

wim niemans