3 ms·
I think me and you have some different definition of canonical: http://www.wordnik.com/words/canonical http://www.wordnik.com/words/canonical All I see are th
by zedshaw 16y ago
I think me and you have some different definition of canonical:
http://www.wordnik.com/words/canonical http://www.wordnik.com/words/canonical
All I see are things about religion, dressing like the status quo, and other things that say "old way of doing things". I think you mean to say "official" or something like that. Let's use official.
In this case, the config file you use is the "official" configuration. If you use the m2sh format than that's the default official format. If you put those into version control then you have solved your problem.
But then, I'm sure you have some witty reply to this reply to your canonical one-liner:
"Conforming to orthodox or well-established rules or patterns, as of procedure."
- tptacek 16y agoI used the word in the sense of "authoritative"; M-W might say "the most solemn and unvarying part". Which seems like the right term to use for "the form of the config the server actually honors". You chose this as a design feature worth highlighting; you asked for people's opinions about it. I think it's flawed. Other tools I like are flawed in similar ways (tinydns, for example). Don't worry, I'm not leading a movement to overthrow you.
- zedshaw 16y agoSo you meant "official" then. I actually don't mind your rebuttals and over throw attempt, I live for that kind of debate. You just tend to write one-liners that really have no meaning and provide nothing useful as feedback. For example, the problem you describe of a lack of an official configuration exists not because of the storage mechanism but because you have a storage mechanism. If you use a VCS then you have the same problem since the stored version can be different from the actual version running on any one server. That begs the question how what's on the server gets to be different from the "official" stored version, and in this case it's people. It's always people. So, let's look at the two mechanisms and compare: 1. VCS and just a config file means you have no idea who changed that config file. It's not in the VCS remember? Post crash forensics are then difficult and you really only have a diff. 2. VCS, a config file, and a sqlite storage with commit logs (we have those, you can see who changed stuff) means you have diffs of the config file from the VCS, and logs from the sqlite database. Diff the config in the VCS just like before, and if someone is going in the super back door to run SQL behind the scenes (which I don't get), then you know they did it. If they use the tools then you have the commit log in the datbase. You've now got way more data than you did with just config files. But, if I were to extrapolate your real complain it is probably this: "When the server breaks, I can not run 'diff' on the sqlite3 database config and see what changed some jackass could run raw sql against it and I would never know. Can I please have a way of comparing a given database to what a config file would produce? Kind of a config delta?" With that in mind, I present to you the m2sh diff command ticket: http://mongrel2.org/tktview/9e57f999d5cf23d899858521260b104b6ded43e8 http://mongrel2.org/tktview/9e57f999d5cf23d899858521260b104b... Thanks man!
- tptacek 16y agoI'm glad I was able to help you clarify your design. The "diff" command you propose seems like a lot of machinery just to make up for the fact that your design --- which is, in essence, a Unix take on the Windows Registry --- doesn't have a canonical human-readable form you can just pop open in a text editor. In the interests of full disclosure: I'm very unlikely to ever use Mongrel2. My goal isn't to provide you with useful feedback. Instead, you opened up a conversation about this design decision, and I think the fact that it's prone to a particular failure mode is relevant --- especially to the (presumably numerous) HN readers who might think of emulating you. I hope you read the "what year is it" comment as a judgement on INI files though, and not your code. We appear to share an opinion about INI files.
- zedshaw 16y agoI'm glad I could help clarify your FUD. > which is, in essence, a Unix take on the Windows Registry Ah, the windows registry canard. You are the canard king man. Let's see you've pulled out djb and windows registry. I think your next linux fear buzzword will be "embrace and extend" or possibly "free as in freedom". That'll really enhance the F in your effing statements. The flaw of the windows registry is not that it wasn't a text file, but that it was a massive monolithic database with all software configurations in it and no enforceable schema that couldn't be examined. Our database is only for mongrel2 and has a solid clean schema everyone can go look at with "sqlite3 .dump". So that's a pointless comparison. And you keep using this word "canonical" where it doesn't apply, so let's use official. The "official" configuration file is loadable into a text file, but again, I think that's irrelevant for the use cases the design targets. Either you're doing your own setup and m2sh with mongrel2.conf is fine, or you're doing large scale automation and the database is better. In my design you get both, plus more choice. In your design you only get the status quo configuration which sucks. Also, if I do m2sh diff it'll be just for fun. Nobody really needs that since most people don't hire Ninjas.
- tptacek 16y agoI responded to this comment here: http://news.ycombinator.com/item?id=1777507 http://news.ycombinator.com/item?id=1777507