Using the sqlite db as the canonical configuration is a nice idea, but reminds me of the fun of bind, editing one file to re-generate another. It is as if he is ignoring the advice in his older post about making software usable.
Instead of having a simple text format that is the configuration, he encourages everyone to write their own. I can imagine the fun now on a mailing list - debugging n+1 languages to start a webserver.
When you deploy, do you deploy the sqlite database file or the script that generates it? Does the daemon check if the db is out of date on startup? Does the script clear the existing db when it runs? Does it have merge logic? How do you keep them in sync?
'But it's powerful' I hear you cry, but my retort is simply 'it is effort to maintain, deploy and configure'. It smacks of: here is a bus port, go build yourself a keyboard. This sort of toolsmithery is what brings us delights like autoconf.
A simple change would improve things a lot, whilst maintaining the flexibility he craves:
instead of 'generate a config file' with your tool and hand it off to mongrel, the tool you write is part of mongrel.
You write a script called /etc/mongrel/makeconfig, that takes one argument, the name of the mongrel settings database. When mongrel starts, it invokes makeconfig to build the database.
You can provide a bunch of trivial makeconfig scripts as defaults, including a shell script that just runs a bunch of sqlite statements.
> Instead of having a simple text format that is the configuration, he encourages everyone to write their own.
Uh no, you obviously didn't read the article where at the end I show you the default format we provide to you in m2sh. I think before you go waxing poetical about something you should learn more about it.
And it's not powerful, it's simple. Take a look at the code that loads the configuration in mongrel2 from sqlite, and compare that to similar C code (also written by me) in the m2sh source to just parse a config file. Code doesn't lie and in this case, parsing a config is a hell of a lot harder than just loading it out of a sqlite file.
parsing a config is a hell of a lot harder than just loading it out of a sqlite file
Is there really no library for that? </rhetorical> The usual INI file format has been unchanged since the 80s!
[section1]
param1=value1
param2=value2
; this is a comment
[section2]
param3=value3
And the reason it's stuck around for so long, on every platform you can think of, is it works, it's bulletproof, and everyone understands it at a glance. Anyone can come up with their own scheme, then you end up how it is Javaland right now, where the "application" is just a runtime for the application written in a custom one-off language which is the 10,000-line XML configuration...
Anyway, the people who get called at 3am when production is down won't thank you for introducing yet another config file format.
Agreed, the potential issue of having different people having different configuration sounds a bit dangerous. OTOH, most issues you mention are true whether you use a db or a plain configuration file - they are just more explicit with sqlite3 (which acts as the model in a MVC organization of your app settings).
Incidentally, I am thinking quite hard about those issues (configuration representation, live change/querying, versioing) for internal apps, it is not an easy issue once your app has more than a few parameters.
Instead of having a simple text format that is the configuration, he encourages everyone to write their own. I can imagine the fun now on a mailing list - debugging n+1 languages to start a webserver.
When you deploy, do you deploy the sqlite database file or the script that generates it? Does the daemon check if the db is out of date on startup? Does the script clear the existing db when it runs? Does it have merge logic? How do you keep them in sync?
'But it's powerful' I hear you cry, but my retort is simply 'it is effort to maintain, deploy and configure'. It smacks of: here is a bus port, go build yourself a keyboard. This sort of toolsmithery is what brings us delights like autoconf.
A simple change would improve things a lot, whilst maintaining the flexibility he craves:
instead of 'generate a config file' with your tool and hand it off to mongrel, the tool you write is part of mongrel.
You write a script called /etc/mongrel/makeconfig, that takes one argument, the name of the mongrel settings database. When mongrel starts, it invokes makeconfig to build the database.
You can provide a bunch of trivial makeconfig scripts as defaults, including a shell script that just runs a bunch of sqlite statements.