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.