3 ms·

So 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 t

by zedshaw 16y ago

So 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 ago
I'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 ago
  I'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 ago
    I responded to this comment here: http://news.ycombinator.com/item?id=1777507 http://news.ycombinator.com/item?id=1777507
- protomyth 16y ago
  "My goal isn't to provide you with useful feedback." Shouldn't that actually be the default goal of any reply?
  - tptacek 16y ago
    It would be if I was commenting on Shaw's blog. It's not, by default, on HN. Here, the goal is: discuss.
- bradleyland 16y ago
  I choked on the whole SQLite configuration aspect of Mongrel2 as well, but I continued to read further and started to see how it ties in to the entire mongrel2 philosophy: "Mongrel2 is an application, language, and network architecture agnostic web server that focuses on web applications using modern browser technologies.". Agnosticism is important to Mongrel2. If you open your mind to the concept, you can begin to see how using SQLite for configuration becomes a bike shed in the entire scope of the project. If I'm a shop looking for a single web server to host apps written in a variety of languages, chances are that I'm going to have an opinion about the process used to configure and administer that server. That opinion is going to include the structure, process, and implementation of the entire server and management tool stack. The same thing happens with servers that use plaintext configuration formats as well. Have a look at the differences in Apache administration on Redhat based distributions versus Debian based distributions. Look at the number of tools that exist for managing Apache conf files. True, not everyone uses them, but the manageability of editing these text files by hand only scales so far. At some point, you turn to a tool that abstracts away the underlying (canonical?) configuration file. At that point, the underlying format -- text or SQLite -- becomes less important. Hence, Zed's repeated referral to this whole issue as a "bike shed". What I think is really cool about this entire approach is that there will likely be a wide variety of tools built to manage different types of Mongrel2 hosting environments. The power of SQLite will come to bear when implementing these tools. SQL is a powerful tool for collecting and updating information. There are plenty of text libraries that perform similar tasks, but text is a lowest common denominator. At the end of the day, I think it's a pretty interesting choice.

by zedshaw 16y ago

tptacek 16y ago

I'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 ago
I'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 ago
  I responded to this comment here: http://news.ycombinator.com/item?id=1777507 http://news.ycombinator.com/item?id=1777507
protomyth 16y ago
"My goal isn't to provide you with useful feedback." Shouldn't that actually be the default goal of any reply?
- tptacek 16y ago
  It would be if I was commenting on Shaw's blog. It's not, by default, on HN. Here, the goal is: discuss.
bradleyland 16y ago
I choked on the whole SQLite configuration aspect of Mongrel2 as well, but I continued to read further and started to see how it ties in to the entire mongrel2 philosophy: "Mongrel2 is an application, language, and network architecture agnostic web server that focuses on web applications using modern browser technologies.". Agnosticism is important to Mongrel2. If you open your mind to the concept, you can begin to see how using SQLite for configuration becomes a bike shed in the entire scope of the project. If I'm a shop looking for a single web server to host apps written in a variety of languages, chances are that I'm going to have an opinion about the process used to configure and administer that server. That opinion is going to include the structure, process, and implementation of the entire server and management tool stack. The same thing happens with servers that use plaintext configuration formats as well. Have a look at the differences in Apache administration on Redhat based distributions versus Debian based distributions. Look at the number of tools that exist for managing Apache conf files. True, not everyone uses them, but the manageability of editing these text files by hand only scales so far. At some point, you turn to a tool that abstracts away the underlying (canonical?) configuration file. At that point, the underlying format -- text or SQLite -- becomes less important. Hence, Zed's repeated referral to this whole issue as a "bike shed". What I think is really cool about this entire approach is that there will likely be a wide variety of tools built to manage different types of Mongrel2 hosting environments. The power of SQLite will come to bear when implementing these tools. SQL is a powerful tool for collecting and updating information. There are plenty of text libraries that perform similar tasks, but text is a lowest common denominator. At the end of the day, I think it's a pretty interesting choice.