On Thu, 23 May 2002, Beck, Mike wrote:

...

I never even proposed to keep the configuration file in an XML format. I am just using an XML format to store it in the DB for DB-Config as XPath is the only way I can find to select certain parts of it to take effect.

hmm well that is the part i don't understand. the way i understood feature request "[ 485311 ] (DB-Config) Storing Server Configuration in Database " was that we would have the $cfg['Servers'] Stuff in one database so it can be read into the configfile, which i thought would be rather straightforward, i don't see why you need to store XML in the database to achieve that or to put it the other way what you can possibly achieve by putting xml into the db instead of some traditional SQL setup?

I would encourge you to read back on this mailing list, to see some of the postings a few weeks ago about it.

Firstly, my reason for storing it in an XML form in the database: While I was looking at using serialize($cfg), I wanted to make the choice of format inside the DB human readable. So XML based worked well.

Furthermore, serialize($cfg) stored the entire $cfg variable, whereas there were some settings that we do not ever want going into the database, for security reasons mainly.

Additionally, there were going to be two levels of DB-config used. DB-Config will never replace the configuration file, only supplement it.

The load order will be: 1. configuration file 2. master DB-config data (global settings, nearly everything outside $cfg['Servers'] and a few bits inside possibly) 3. user DB-config data (visual and display behaviour preferences only)