The responses to my previous weblog article made me think about centralized configuration a lot. I've decided not to implement database support in Hiawatha. That's simply too much work, adds too much complexity and makes Hiawatha too much bloated. I also don't like the idea of constantly connecting to a database for every request. The whole idea simply doesn't feel right.
So, what else? Before explaining my new idea, I just want to make clear that the original way of loading the configuration from a file will always be available. That will never change. Any centralized configuration storing will just be an extra option. Now, back to my new idea. Instead of using database connections, I can make use of the type of connections Hiawatha already knows best: HTTP. What if the local configuration file only contains a single option which tells Hiawatha to which webserver it can connect to to retrieve its configuration? Hiawatha connects via HTTP(S) to that webserver, downloads the configuration file and handles it like it was loaded from a file. That's not hard to implement.
Now the changing of the configuration without restarting the webserver. Simply reloading the configuration is not an option. It's simply too complex. What to do with the old configuration upon reload? It's very likely still in use for the current connections. What to do with changes in binding configuration? Kicking all clients after configuration reload is the same as a restart. This whole configuration reloading is simply asking for trouble, so I won't go that way.
My biggest question in all this is: how bad is restarting a webserver really? Those 2 seconds offline time, does it really hurt anybody? And how fast does a new website need to be online? What can be done is a cronjob that checks every night for a configuration change and restarts the webserver if so. Is that acceptable? If so, the solution is simply. It's like I just described. If not, there are some options, but I haven't figured out which I think is best.
One option is to use some sort of dynamic virtual host configuration. A special configuration option points to a directory, in which each subdirectory is named after its virtual host. So, simply adding a new directory adds a new virtual host. This works only if a new website is comparable to the other websites (same URL toolkit, same FastCGI daemon, etc). Otherwise, adding the extra configuration options for that new virtual host makes it all more complex.
Another option I thought of is to make the centralized configuration server use some sort of POST request to the webserver, with the new virtual host or URL toolkit as the request body. This makes it more flexible than the first option, but making sure the configuration that has been pushed to the webserver is in sync with the one stored in the database adds extra complexity.
Both options can be implemented as an extra feature of the Hiawatha Monitor. That way you have a centralized tool to maintain your webserver configurations and to keep track of their performance and status.
Although there is still a lot to think of and to work out, I like the general idea of it a lot more than the previous idea (using database connections). This simply feels more right. I'm really interested in your thoughts about this idea.