Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id AAA22133; Sat, 23 Aug 1997 00:28:07 -0700 (PDT) Received: from veal.organic.com (h20.n145.organic.com [204.152.145.20]) by hyperreal.org (8.8.5/8.8.5) with ESMTP id AAA22127 for ; Sat, 23 Aug 1997 00:28:03 -0700 (PDT) Received: from localhost (akosut@localhost) by veal.organic.com (8.8.3/8.6.12) with SMTP id AAA21938 for ; Sat, 23 Aug 1997 00:28:00 -0700 (PDT) X-Authentication-Warning: veal.organic.com: akosut owned process doing -bs Date: Sat, 23 Aug 1997 00:27:59 -0700 (PDT) From: Alexei Kosut To: new-httpd@apache.org Subject: Re: thoughts on a new config language In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Fri, 22 Aug 1997, Dean Gaudet wrote: > Definately not 1.3 ;) No, but maybe 3.1 :) > Ok, so I bitch about the config language ... and I should back up my > bitching with at least a message describing something I think is better. [...] > Anyhow that should be enough to get the debate going. WARNING: This message starts with Dean's idea, and then goes off into an odd world that only exists in my imagination. You've been warned. I think this is an interesting idea. I'd like to see a more detailed description of how your scopes relate to how the module's configurations end up when it finally comes time to start the server, but I kinda like it. I think, though, that you're better off making the *config file* format secondary, instead of primary. In other words, instead of defining a grammar, define the low-level configuration structure, and write some APIs on the C side of things to deal with it. It looks like your idea basically is this (and I'm making up terms): The configuration consists of a list. This list contains a number of entries, each of which has a named label. This label can be either point to another another list (in which case you continue recursively), or the label can be the key to a key/value pair, which contains actual configuration information. The labels are all one-word text strings, the possible values of key/value pairs are dependent on the specific key, but are some sort of expression (see Dean's email for a good explanation of possibilities - ints, strings, regexes, ipaddrs, lists of the previous - oh, and booleans, with Dean forgot, and probably a few others) That seems like a pretty simple way of defining the configuration of Apache. Then you can write, to that API, any method of configuring Apache. You could writer a parser to use your new grammar, with lex and yacc and such: directory { match "/abc"; core { hostnamelookups off; } } You could write a parser that used the current style of Apache configuration: Match "/abc" Hostname-lookups Off (obviously existing Apache config files wouldn't work, but most users are probably more comfortable with this than a C-style syntax where they have to worry about semi-colons and bracket matching and things) You could write an HTML-based configuration utility that showed you this in some format. Or use Java (though obviously it would have to have a bit of C to talk to Apache's API). Or, even better, this scheme maps directly into the form used by the Windows NT registry. And so on. It's simple enough that any configuration tool can use it, but still powerful enough to do everyhing we need to do with it. And the modules wouldn't care. They would just define their directives using an API that only gave them access to the very basic constructs (lists, key/value pairs), and you could plug in any tool you wanted that configured Apache. One problem with GUI-based configurations is that they're often impossible to have a file-based configuration, because the files are machine-generated. It's likewise hard to write a GUI for a text file-based config system like Apache, because it's hard to fit a GUI into the constraints (and oddities) of a text-based system. So I think we just make the configuration of Apache blind to the user. Okay, so you wouldn't be able to take your text files and just magically switch to using a GUI (unless that GUI tool supported importing the text file format you're using), but I don't think that's a big issue. Apache isn't that tough to configure, and it's likely that you're likely to stick with one tool once you start (how often do you switch text editors, for example? And you don't expect vi to be able to read your .emacs file) Anyhow, Dean, I like your idea. And I think mine might be a good way of implementing it. And making happy those people who want to be able to configure Apache with the NT Registry, or with SNMP, or whatever. -- Alexei Kosut