Is "educate your boss" no longer an option these days?
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.
The more education your boss needs about a new technology, the less likely he is to allow it's use.
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.
(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.
The canonical version of the server configuration doesn't play nice with version control, and so staff has to work with a facsimile and hope that nobody makes out-of-process changes.
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.
Part of the idea behind mongrel2 and using sqlite is that there isn't supposed to be a canon config script/format thingy. Baking m2sh into mongrel2 so you can pass it in with a flag canonizes it.
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.
Unless I'm remembering wrong, isn't one of the benefits of using sqlite in this context that you get configuration persistence, live configuration modification, and customizable configuration frontends? The suggested solution, loading a dump file into a temporary database during start up time, completely defeats the purpose of all of these. It may be difficult to convince PHBs to use this because it's "different than other tools", but really, PHBs are going to complain about arbitrary things like that anyway (the manager who complaints about this isn't the one who has to learn the difference between the lighttpd and apache config file formats, for example). These are good goals for modern services to have.
Don't so it, Zed. The bikeshedders don't need a bone.
To clarify, I wasn't proposing to eliminate any of this.
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).
M2s zero mq awesomeness, for me, is balanced out by the need to recreate init scripts, config files, and other things that all my other apps use. I'm not opposed to zed replacing these, its just that I think this non web server related work belongs in separate projects. Having all these new things to learn and understand makes setting up m2 way more complicated than it needs to be.
The documentation that is there on the site is absolutely excellent - first there is a document that can get you a running server within a few minutes:
I went through the getting started guide two months ago and at the time it pointed new users towards m2sh and had no mention of config files. Did something change in your docs?
I don't see how your proposed solution affects either your first or second cases.
"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 :).
The only real difference between this and m2sh is a social one. I agree, in addition to a `-dbtxt` option, one could also include a `-dbm2sh` option. I added to the post to reflect your suggestion.
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.
In this case Zed made a design decision to have a common target format for the config (which I personally applaud).
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.
> 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?
That's a good point. Mongrel2 config files == .c files, m2sh == make, config.sqlite == libmycodez.so
This is number ONE on hacker news? Way to go seriously down hill guys.
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.
Mongrel2 may be enjoying some popularity because Zed wrote it, but Zed isn't a celebrity for no reason. Mongrel was a pretty damn good idea. He's also written interesting articles on his design decisions to come this far, and explained himself quite thoroughly. I think a lot of the HN community is eager to see where this goes.
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.
1. It's a slow Sunday, go outside.
2. There are not millions of web servers, unless you mean deployed then there are way more than millions.
3. You're right, the only reason anyone cares is because I wrote it. Just move along and don't go use it. Nothing for you here.
4. You're right, this being on HN is absolutely stupid. But hey, people try to have lives any way they can.
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.