On Tue, Jan 13, 2009 at 2:16 PM, Damien Katz <[email protected]> wrote: > I see the danger of the admin setting a value that then disables the server, > they could do that anyway by editing the ini file. I think instead of > validators, we should just contain a stern warning in Futon that any bad > change to the config could cause the server to crash and un-restartable and > to repair it they will need to manually edit the INI. >
A stern warning doesn't catch typos, mis-behaving scripts etc. I'd rather have an error thrown when something unexpected happens instead of crashing a production environment. I very much disagree that we shouldn't make some effort to inform people that a change will break things catastrophically. > The problem is Config validators are trying to provide training wheels to > the users who need and desire it least, administrators. And we can't be > expected to validated every input to see if it will work properly before it > takes effect. Changing the config is inherently dangerous. > So basically we should just stand at the edge of the cliff and watch administrators jump off and go splat? I don't see why you think of it as training wheels for new users. Administrators are very capable of making mistakes. We may not be able to check every possible config permutation for safety, but we can catch quite a few silly errors. > I completely agree giving nice error messages on start up when possible is a > very good thing, but we don't need validators to do that, we just need to > add it to the code in each module's init code to print nice error messages > for common failures. > Config validators were intended as a way to take the error detection code out of the init function and put it somewhere that could be run when the config changes thus providing the entire facility for runtime checking. To me its a simple system with a good cost/benefit ratio. Paul Davis > -Damien > > > > On Jan 13, 2009, at 1:48 PM, Ulises wrote: > >>> And I choose a slightly modified form of 2, but have the config module >>> call each registered validator immediately and then close things down >>> if one fails. >> >> The problem is that validators are registered asynchronously so, from >> the config's point of view, you can't be sure you've ran them all once >> you're done loading the config. From the module's point of view, >> however, once you start pulling values out of the config you know >> they've been loaded. I think that checking that a value is valid in >> the init() of a module might be a better approach. >> >> Generally, though, does this whole validators thingie make sense? >> >> U > > >
