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.
> 
> That's opinion 1. Current Conf preLoads. Next Conf too. Solved.

Currently Conf included php files (xml is transformed into php by 
phing+xsl). I'm afraid reading many conf values from db will be slow. 
That's why I propose a cache as php files.

>>Whereas including a php file caching all confs is easy and probably fast.
> 
> Conf: caches. Solved.

Ah, so you agree?

>>Db is useful to maintain the list of values and have a gui to edit them.
> 
> That's opinion 2. It's coded. Solved.
> 
> There is something more to evaluate.
> First, there will be no user changing the Config in a Gui directly. Since 
> that Gui is using BC as base it is pretty dangerous to make a typo.
> I that case you're done an must re-install.
> So, there must be more to it:
> 1. Change your Config.
> 2. Test it.
> 3. Decide on a point of time to go live with the new Config.
> The Gui must be extremely independent of Conf::.
> The changed values go into the db with version '9999.99' (example).
> At (3) there is a query to install the Config, making a backup of current 
> Config (where? in files?).
> But this all is talking on utilities to elegantly install/de-install.

Agree with all this. Being able to test prod system with new edited 
conf, that would be used for admin user only, whereas all other user 
still see ald conf would be great.
-- 
Jean-Christophe Michel