On Dec 14, 2007, at 6:06 AM, Jacques Le Roux wrote:
De : "Jonathon -- Improov" <[EMAIL PROTECTED]>Like BJ, I had also created my own configurator.As for David's point about deployment management and version control (of config files), I would agree with Jim Barrows. Those who use the UI configurator would use it exclusively, and have someone in charge of documenting all the switches required for a particular deployment. Those who use SVN to version control the switches will have similar documents for the switches, but thedocumentation would exist in non-UI form.How I use my configurator is like this. I first use it to configure all switches (written to file, no storage of settings or configuration flow in database). I then version control all the config files. Each time I use the configurator to change something, I commit the changes switches into SVN.If I understand well, as Adrian outlined, David's concern is with concurrent accesses (Chris Howe seems to look for a possiblesolution using Xindice ?)
It doesn't really have anything to do with concurrency, my concerns is with redundancy and inconsistency. If we put configuration (system or business level) in the database, which is what this discussion was originally about, then the initial data will come from XML data files. If that data is changed in the database but not in the XML files then they are out of sync, and if anyone changes one without the other and the XML files are used for a new system or to update an existing system then strange things may happen (which generally needs to be done periodically since we are not omniscient are rarely create or deploy systems that don't change).
Right now system level settings such as http, database, cache, debug, etc settings are in files and are read from those files; if any of these are changed through a UI then the changes are in memory only. Would we really want a setup wizard for these things? We certainly could, but what is the target audience and intended use process?
Business level settings are done a little differently, and this is where the biggest inconsistency lies. Some of these are in properties files and others are in the database. In order to have different industry-specific or business type specific data sets these that can be loaded initially when setting up a system these really should be all in the database and configurable through UIs rather than sitting in properties files.
I really think the more important things to allow users to configure are the business level things. The system level things might be nice, but most of those settings should stay the same for really small installations where they are using it OOTB. If we did make a config UI for system level settings in order to make it easier for non-technical users to change things they just might use it... and that could be bad! Most of the system level settings require an understanding that non-technical users wouldn't have, and we shouldn't make it easy for them to hork their entire system and require someone more technical to come in and try to figure out what they did, undo any damage (if possible!) and then tell them NOT to use the fancy UI we built anyway...
-David
smime.p7s
Description: S/MIME cryptographic signature
