Zed, I think the narrative in your docs is partly to blame.
It starts with an awesome sqlite config engine, and continues, almost as an afterthought, to a possible application: a python-like configuration file (section 3.3).
It seems to me users want to know about that configuration file first. Sure, some of them will evolve into power users, eager to hear about the internal sqlite3 engine and its endless possibilities. But that's later, and frankly is not as important. What proportion of mongrel2 users will programmatically drive its configuration? I'm guessing not that many.
I for one am an automation freak and am very excited about this design. But you can't blame everybody for misunderstanding it. After all, the very first command in the tutorial has "config.sqlite" in it. That's before you talk about the actual config file format!
Almost as funny as "You write a distributed map-reduce function in Erlang!".
I think people are reacting out of bad experiences with other binary file configuration systems. Examples: windows registry; Solaris as LDAP client (ok, so the stored files might be text today, but the documentation disavows their format and declares the command line is the One True Interface); Solaris smf (again, text files underneath, but the documentation deprecates their format); Gnome configuration (I'd be grateful if someone could point to useful documentation there, or some kind of road map).
Funny you mention GConf, since its storage engine is based on text configuration files that you can edit by yourself (not binary and in fact those text files are even human readable).
I mean, I'm a power user and I like Apache's configuration format, but there was a steep learning curve involved, and for a production server that's super-duper fine, but for normal users it is super painful to deal with different syntaxes / conventions / locations for every god damn application you're using.
GConf sucks, but the alternatives are worse.
Also, the technical problems of Windows Registry have more to do with it being a half-arsed implementation of a filesystem, not to mention inappropriate use of it (many apps using it as a database).
Per the parent poster, 99% of apps with a config file and an initscript mention the config file in their 'getting started' docs. M2's doc doesn't do this (but has time for inline rants). Zed's not great at writing docs, which is fine, but he doesn't really seem to want any feedback about said docs either - his normal response if anyone doesn't get anything from reading his docs, or suggests anything, is to get angry at them.
Edit: actually I see, 2 months post abuse, the Getting Started guide now has less rants, and a config file. Cheers Zed. That wan't so hard was it?
Nope, I'm not, I'm pointing out the idiocy of assuming this is a probable risk. The chance that someone does this on accident is non-existent at best, and recovery is simple. The only remaining option is that someone does it intentionally, and then again, if they're doing it intentionally then you are screwed anyway.
The post is against all the people who say stupid things like "mongrel2 doesn't have config files I can put in git" when I've got config files I put in fossil. It's a stupid statement that's just false, and this was the latest reason they gave for saying it was a "real world" concern.
I have had to maintain databases where the dumps were useful and others where there were so many inter-table references that figuring out what the changes did was painful.
I've only written toy projects in m2 ("look ma, long polling"), so take everything I say with a grain of salt. What I do is manually edit the sqlite dumps. The data flow is one way - edit sqlite dump, import to sqlite, run. I never import and then export the dump.
Actually, I don't do any of this. The sqlite file is in .gitignore, and run_my_app.sh does all this. As far as I'm concerned, I just manually config.sql and mongrel2 reads it. If I type ls, I see config.sqlite as well asmy_app.pyc and a few other files I ignore.
In principle, I imagine it might be less than useful if you edited your config with some complex sql query. Then again, if you do that, you can't complain the config isn't raw text.
Incidentally, why are people downmodding Zed? I don't get it - is his reply to a direct question really harming the conversation here? I'm now thinking I was simply wrong in my proposed solution - hiding the sqlite file from people won't make them any happier.
Zed, I totally get what you're saying. I do think ninjas exist in larger teams, but maybe that's not a mongrel2 priority, which would make sense.
The bit that gets me that I think some take issue with is that there's a human readable representation of the configuration that does not actually represent the configuration . Except when it does, sometimes. Even usually. But there's no guarantee. Not saying your decision is wrong (any more than "language x os wrong", but it's a reason why some people may not like it.
I almost wonder sometimes if the configuration should be solely accessible through an http API, just to shut people up. ;)
It starts with an awesome sqlite config engine, and continues, almost as an afterthought, to a possible application: a python-like configuration file (section 3.3).
It seems to me users want to know about that configuration file first. Sure, some of them will evolve into power users, eager to hear about the internal sqlite3 engine and its endless possibilities. But that's later, and frankly is not as important. What proportion of mongrel2 users will programmatically drive its configuration? I'm guessing not that many.
I for one am an automation freak and am very excited about this design. But you can't blame everybody for misunderstanding it. After all, the very first command in the tutorial has "config.sqlite" in it. That's before you talk about the actual config file format!