Dear Zed, please throw the bikeshedders a bone
crazybear.posterous.com
crazybear.posterous.com
What if someone edits the sqlite file via sqlite rather than the config file?
Think of the sqlite database as a "deployed" configuration, not the configuration that you work with. Put together some process documentation for deployment procedures, you'll need it anyway.
What if sqlite3 goes out of business? How will we edit the config files? Where can we purchase sqlite3 support?
sqlite is public domain. And if the support issue can kill your proposal, you should be worrying about where to get mongrel2 support, in case Zed falls off a bike.
So now we can't even invoke the server, we need to invoke some complicated shell script? Sounds like a maintenance nightmare.
Congratulations, you've just introduced a fraction of the complexity in apachectl. Have a cookie.
Mongrel2 makes me feel fear, uncertainty and doubt! These are negative feelings!
I don't know about your manager, but mine would definitely cringe with fear, uncertainty, and doubt upon seeing some scary temporary hexadecimal filename.
Oh, and since we're bikeshedding, might as well point out that Step 3 has a useless use of cat. Grumble, grumble.
Think of the sqlite database as a "deployed" configuration, not the configuration that you work with. Put together some process documentation for deployment procedures, you'll need it anyway.
The list of objections your boss might raise were all straw men except for this one: http://news.ycombinator.com/item?id=1777093
(I added a disclaimer to the post clarifying that I'm not endorsing any of these objections.)
As for a scary hexadecimal filename, that's an implementation detail. The raw text sqlite dump is the actual configuration, the /tmp/whatever.sqlite file is deleted when mongrel2 exits. No user need know it exists.
You claim that this is a social problem, and I claim that the solution to the social problem is to have a well-defined process.
Even if the canonical configuration is under version control, that still does not prevent anyone from making out-of-process changes.
Let me clarify: the social problem is that everyone is whining about how they are forced to know that config.sqlite exists. They even need to remember this while writing their "run_my_webapp.sh" script.
I'm proposing a command line option which hides the `m2sh load -config examples/config/sample.conf` step from the user, and stores the config.sqlite file somewhere other than the working directory.
The sole goal is to make people STFU about the config format.
I admit that right now it does seem to be the de facto standard but that's at least partly because the m2 community is small enough that Zed is still important in it so the tools he ships are the tools people use. In the event that m2 takes over the world though an -m2sh (or similar) option is going to be criticized as obsolete bloat that no one needs because every one uses the M2ConfigDeploy.py library.
Don't so it, Zed. The bikeshedders don't need a bone.
I was only proposing a command line option allowing the user to pretend this doesn't exist, if you want to make their mongrel2 configuration "ninja proof" (to borrow Zed's language).
http://mongrel2.org/wiki?name=GettingStarted
Then there's a complete manual which takes probably half an hour to read but is worth every character of it:
"What if someone edits the sqlite file via sqlite rather than the config file?" - well, you've just introduced complexity by making them separate, and disparately maintained files. Previously, there was no config file, and you didn't have this problem.
"What if sqlite3 goes out of business? How will we edit the config files? Where can we purchase sqlite3 support?" - your proposed solution does not address this at all. You are still dependent upon sqlite3.
"So now we can't even invoke the server, we need to invoke some complicated shell script? Sounds like a maintenance nightmare." - doesn't address this at all, and this argument is orthogonal to the other arguments anyway.
While you might be able to make the argument for preferring a config file to SQLite3 (which is an implementation detail), your solution badly hacks together a hydra of both. Go back to the drawing board :).
This is false, there is a config file. Look in examples/configs/ for examles of config files.
People really don't get this. There's a config file, and a config database. Just baffling why people ignore this repeatedly.
I should also emphasize that I'm not proposing this for technical reasons. The sentence where I clarify this is now bold in the post.
Doing what you propose would only bring extra clutter to those who do not have the social problem that you propose to solve with the technology.
Explain the hypothetical boss it is a bit like an ELF format, but for configuration. He does not recompile every executable every time before running it, does he ?
Also, this is not the first time this design decision has been made - as a well-known example you can bring up Chrome and Firefox.
One thing where your suggestion does make sense is where one has to frequently re-edit the config file and restart the server. But that is solved by writing the shell scripts, not by cluttering the core code base, IMHO.
That's a good point. Mongrel2 config files == .c files, m2sh == make, config.sqlite == libmycodez.so
The only reason I can imagine anyone cares about mongrel2 is that it's written by a 'celeb'. Do we really need endless posts about this? It's a webserver. There's millions of webservers. It's a solved problem.
Nothing is a solved problem in this industry. Look at the way the web has changed in the last 5 years. I think it's time to take a good hard look at what we use webservers for, and admit that Apache doesn't support a lot of common use cases very well.