RE: [NeoStats-Devel] Idea's for config/data storage

Justin Hammond wrote:
> > DeadNotBuried wrote:
> > > I've always believed Program Config options should have a single 
> > > format, and not be changeable by any other programs.
> > > if secondary write interfaces are added for config 
> options then it's 
> > > too easy for the data to be changed to something that is 
> invalid or 
> > > unexpected. for example, FloodServ SET JOINFLOODACT, if 
> the data was 
> > > changed to 2, then that breaks all actions when it detects a join 
> > > flood as it is not an option it allows itself. and it 
> wouldn't let 
> > > anyone know a flood was taking place, or take any actions 
> to prevent 
> > > the flood.
> > 
> > I think the current direction is to only allow editing of 
> the new text 
> > based config files. The config parser would then be responsible for 
> > validating the data in conjunction with ModuleConfig, which knows 
> > valid values for a given option. As you suggest, anything 
> which does 
> > not at some point hit ModuleConfig for validation will potentially 
> > cause  problems.
> > 
> > It does of course raise the question of what to do in the event of 
> > error during rehash. Taking your example, if in floodserv.confuse I 
> > change JOINFLOODACT to 2, when I call rehash, do we ignore it and 
> > continue with the current valid setting? Do we write the 
> current valid 
> > setting over the erroneous one? Do we bail until the user 
> fixes it? If 
> > we just warn and do nothing, NeoStats will still have to address it 
> > when it next boots and the only automatic action it could 
> take would 
> > be to override to a default setting which may not be the desired 
> > setting to use.
> > Definitely something to
> > ponder. I guess we could have a SET option for what action 
> we take but 
> > then we have the same problem if this setting itself is invalid :)
> > 
> 
> I think the best is to use the supplied default, and complain 
> loudly about it... And with confuse, we have a choice, either 
> the defaults get "integrated" with confuse, and then it can 
> do its syntax checking, or we keep it as it is now, and have 
> ModuleConfig perform the verification.
> Personally, if we are going to down the road of having 
> "engines" for the config data, leave the verification in 
> ModuleConfig... 

I don't see any benefit in different "engines" for configuration data and
favour using a single approach to all configuration data. 

ModuleConfig does it's verification based on the bot_settings table. If
"integration" means we have to create another table for libconfuse, then I
say we leave it as it is to avoid the overhead of creating and maintaining
two tables where one will suffice. 

Mark.