1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<h2>Criticisms</h2>
<p>The idea for Mongrel2 is slightly controversial, but it has potential. Here's some criticisms about the proposed design, and I'm looking for more:</p>
<ul><li><em>Using sqlite for the config file will be like working with the windows registry.</em> The proposal is to use sqlite as the configuration storage so that you can use any language you want to consistently configure it, migrate configurations, automate configurations, and understand the configuration directly. In no way would I ever let it be like the windows registry.
</li><li><em>Config files are better.</em> The proposal is to create a DSL in a few languages to use as config files, and maybe a converter from Nginx or Apache. Since sqlite is a standardized storage, and the relational model is easily mapped, it would be possible to make the configuration Polyglot.
</li><li><em>It should be event based, not use coroutines or threads.</em> It is event based in that it uses kqueue/epoll/poll/select, but it abstracts the complexity of event systems away using coroutines. You get the best of both worlds.
</li><li><em>Flash sucks, use something else.</em> JSSockets work, and they're reliable. When WebSockets is established and in at least 2 browsers I'll add that as well. Mongrel2 works with long polling but it's not that big of a deal, it's just how Mongrel2 works. It's only a big deal in web servers that suck.
</li><li><em>It needs to serve files.</em> It will serve files, and since obviously that's the first vanity metric everyone uses, it will serve them fast. It's just Mongrel2 will favor <b>language agnostic</b> applications over simple file serving.
</li><li><em>People hate SQL</em> and won't want to use it to configure Mongrel2. Hopefully they won't have to use SQL unless they want to do something advanced. Instead they will use a shell that configures it for them.
</li><li><em>SQLite3 will be slow</em> and won't scale. No, SQLite3 will be just fine, I will not load everything from the sqlite file every single request. That's stupid.
</li><li><em>SQLite3 is not Diff/Git friendly</em> so I can't use it. Yes, the sqlite3 file is not, but the plan is for you to be able to replicate changes to your config using migrations, same as you do in Rails, Django, or any modern web application. Those migrations are definitely Diff/Git friendly.
</li><li><em>SQLite3 will be hard to change quickly</em> so I'll be stuck in an emergency situation. It's a SQL database, it's all about changes, and you won't use SQL directly, so this is just plain wrong. Not only will you be able to change it quickly, but you'll be able to replicate those changes to all your servers in one shot, roll them back, and lots of other great features.
</li><li><em>It will suck for developers</em> because so much emphasis is on operations. No, it will obviously be for both, it'll just be focused on operations needs before developer needs. You will of course still get your "5 minute quick start" and be able to fire up your application quickly, just like all the competitors.
</li><li><em>SQLite cannot handle hierarchical configs like in NGinx.</em> First, people mean that SQL has a hard time putting trees into tables, which is true, if the structure is self-similar and arbitrarily nested like a comments system. The NGinx configuration file is <em>not</em> hierarchical in this way. You cannot put server stanzas in themselves, nor locations in locations, nor pretty much any real hierarchy. The truth is, the NGinx config is actually a more limited form of tables and relationships, with servers having many locations, locations having many proxies, etc. SQLite3 can handle this just fine, and can handle additional relations a config file can't, like attributed and ternary relations.
</li><li><em>Version Problems With Ubuntu And Other Debian Systems</em> "When you install fossil you need a certain version of SQLite3 or it won't work, this means that Mongrel2 will have the same problems." Like all software systems, if you want to use advanced technology you have to keep the system up to date. If we all waited around for Debian to get its shit together and properly release modern versions of their software, then we'd still be using Apache1 and Linux 2.0. Instead, we're making a modern piece of software that requires modern technology and yes, that means if you are unflinching in your software versions then you will not use Mongrel2. Additionally, this applies to the use of SQlite3 in fossil, not in Mongrel2. Fossil's requirements are much more advanced that Mongrel's since it's a complete version control system that stores a distributed file system in SQL. <b>We're just storing URL and port numbers mostly.</b> Finally, any choice in libraries has this limitation. No matter what you choose, some Linux distribution will not have that version, and the only solution is to just write everything from scratch. Personally, I don't have time to write everything from scratch, so I'm going to use libraries. End of discussion.</li></ul>
|
