On Tue, 2009-02-17 at 07:55 +0300, Mohammed obaidan wrote: > Hi, > > Apache is not for web server admins. what about developers? What about > home servers? What about users that needs a certain web application on > their intranet? do they need to be web server admins to use Apache? > certainly not. > > Most of the posts here suggests that people here are Apache admins and > they think that such a tool is useless because they can use a text > editor to configure Apache because they are Apache admins.How about if > you are not an Apache admin? I do not think you are going to hack a > text file for adding a virtual host or an alias without a certain tool > that can display information about such directives and validate that > for you. > Just an aside; I wasn't born as an apache admin. I didn't go on a course that made me an apache admin. I wanted to install apache and make it work, which means understanding one reasonabley large, extremely well documented file, and then reading a bit of the manual. I started doing that 8 years ago, and I still read the manual when I need to change things. The problems I think you will encounter in writing a tool to configure apache are 1) Lots of people will be very familiar with apache syntax, and won't be with a gui tool. 2) Loss of flexibility; in a text editor, all options are available to the insightful, but in a gui tool you only have available the options that the author deems useful. This means if you ever do anything outside of the tool, then you need to know exactly how apache configurations are put together. 3) Loss of community; in a text editor making changes to stock is straightforward and explainable - "I downloaded 2.2.11, did the default install and added 'ServerAlias localhost.localdomain'." compared to "I added an extra site to the server aliases tab". With the tool, only the writer of the tool can advise the users, without having to grok entire conf files. 4) Distro incompatability; apache can come in lots of different config layouts. It would not be possible to predict all of them, especially as many people (myself included!) roll our own layouts, as the task requires. 5) Validating and parsing the config file; because of 4), you would need to be able to parse and validate the apache configuration files. To do this, you need to know whether a directive exists, and whether its value is correct or not. The only way to find out if a directive exists is to load all the specified modules from LoadModule lines, and find a directive that matches. Having found the directive that matches, the only way to check whether a directive value is correct is to call the directives configuration callback with the supplied values. Obviously, part 5 is tricky! The simplest way to avoid that is to write your own parser, which only knows about the modules and directives that you have told it about. Even then, you will need to take logic that already exists and works (config parser) and rewrite it in a simpler, less capable form. Even a 1st year CS grad would know that isn't a good long term plan! Writing your own parser (even if you used APRs config parsing routines for parsing apache-style config files) will require knowledge of how apache works. For instance, if I have the file /etc/apache.conf, which contains these lines ServerRoot /usr/local/apache22 Include "main.conf" then your parser will need to work out to read /usr/local/apache22/main.conf not /etc/main.conf. If /etc/apache.conf just contained this: Include "main.conf" then you would need to do even more, you would need to see what default directory was compiled into apache for the ServerRoot! So, I think a lot of people do not warm to this idea because it is a lot of work, wont work as effectively as a text editor + manual, will be harder to maintain, and (especially on this list) will be much much harder to support users using this tool. Good luck scratching your itch! Tom --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|