Hacker News Reader

Comment by lsb | Hacker News Reader

I like that the configuration language is a sqlite database; sounds far easier than parsing ini files, for example.

I don't like that idea, because of one simple limit. You cannot diff databases (easily). Of course you can dump them, make sure the linebreaks are there between records, make sure they're sorted, etc. etc. But checking the whole config in or out of a VCS is much more useful in general. It also provides an easy to browse record of changes.

If diffing is important, why not use Git as the repository back-end, then?

It doesn't matter which VCS. If you check in text, you can review the changes. If you checkin databases, all you get is a blob. Git is not magic and will not solve this problem.

The sqlite database might get stored as a blob, but a json, xml, or sql dump of the database would be just as plain text as anything else.

Think of it like this. Zed is combining Apache's nonstandard configuration language with it's internal runtime representation of such. He's doing it in a way that's standard and manipulable at runtime. So changes to the runtime configuration are persistent. You can fix that. That's the beauty of it. It's an incredibly simple and flexible idea that builds upon existing, robust, and standard software. If you want to diff config files, then you could slap together an XML, JSON, or any other representation of your config data and write a loader for it.

Isn't reading from sqlite all the time a bit bad for the performance?

Wouldn't the server only read it after a config option has been changed? I don't think the server is going to check this database every time a request comes in.

adamtj said "manipulable at runtime", so I guess he meant the changes are available directly after an UPDATE.

How can you tell if the config is changed? You either poll it every time with SELECT (SQL) or see if the timestamp of the database file has changed. (If SQLite works this way. I never had the need to check on the file status.) This costs time as well.

Other web servers have a config file and reload it after getting signalled.

But: It's a bit early to say what Zed intends with SQLite. Maybe mongrel2 gets a configuration interface like Cherokee and only reads the DB on startup and after getting signalled.

I'm aiming for operational understanding of the data model used over being able to directly work with the config file. If it's a .ini (or other conf) usually you have no idea how the config maps to internal data structures. It's a mystery why some stanzas in nginx work on FastCGI but not Proxies for example.

With a sqlite3 based "config file" you'll be able to use real, turing complete languages to configure it, create control pannels, distribute the config reliably, and you can run .schema to figure out how it's structured.

It's also incredibly reliable and has many great features for this kind of thing.

Isn't the nginx's problem solvable with consistent implementation and complete documentation too?

I guess running some programming script isn't that bad to configure the server - but right now, people do a lot of basic operations on configs via shell scripting which do the deployment. Using bash/sh to interact with sqlite doesn't sound very inviting.

Possibly, it's a littler early to tell, but I'm sure I'll make it easy to use from the shell. Could even be possible to create converters from other config file formats to the Mongrel2 data model as well.

ini files are

1. a straw man. The Format is very generic, only sections and key-value-pairs. A fairer comparison would be against httpd.conf, or other languages actually used for web server config.

2. Easy to parse, because there are tony of implementations already.

3. Static, like a SQL database, although Zed[1] and others[2] argued we need Turing-complete extension and configuration languages like Ruby.

[1] http://vimeo.com/2723800 [2] http://lambda-the-ultimate.org/node/3606

An even fairer example would be ngnix.conf

He says that a config file is half-turing, but an sqlite database can have no turing. Won't this make the configuration far more complex?

Just wait till someone uses an ORM library for configuration.

But how would one represent a configuration like "don't require auth for /, but do require auth for /foo/*.jpeg" in a table? It would be great to just use a row for each possible URL, but with overlapping wildcards, folder hierarchies and multiple levels of allow/deny it gets very complicated very quickly. Granted, the allow/deny and order that Apache uses isn't great, but at least a configuration is understandable by reading it because the admin can lay out the configuration file with whitespace and comments in a way that makes sense. The equivalent might be achievable in sqlite, but it would be very challenging. It's basically a step backwards towards a poorly featured, confusing GUI configuration mechanism like the old IIS configuration used to be.

well you could always just represent it as:

insert into rules (rule) values('don\'t require auth for /, but do require auth for /foo/*.jpg')

The use of a db is more to create a standard networkable interface for other clients to read/modify the config than a statement about the semantics of the config syntax.

You could do that, but would it really be much different from this?

data = config_file.read()

"insert into config (config) values ('%s')" % data

> But how would one represent a configuration like "don't require auth for /, but do require auth for /foo/.jpeg" in a table?*

Are you confusing offline representation with a runtime structure?

I was only being half serious (or half joking, depending on how you look at it).

Reply on news.ycombinator.com