On Mon, 23 Jun 1997, Randy Terbush wrote: > On that note, can I turn the conversation back to some type of API > to the config information? By adopting an API, a change in config > file format can be transparent to GUI developers.
First, with an API inside apache we would have to rely upon the stability of the main httpd server itself.. I dont think we can rely on this.. Second, the httpd would have to be running to reconfigure it... I would think that some sites would initialy like to completely configure the server BEFORE providing external access. Third, I dont think JUST the file format will be changing in 2.x I would guess that there might be new directives, etc.. were would have to take into account for these new directives anyhow (which will require source modification on our part AND their part).. Fourth.. it would be really nice if we could develop this GUI interfact independent of the work the apache developers are doing. (not bother them) > I'm including again the suggestion I made last week. Is this too > high level? > > For example: > > telnet config.yourserver.org 8080 > Password: ..... > config> > config> show config > .... output of config in familiar format .... > > config> show config vhost www.someotherserver.org > <VirtualHost> > ServerName www.someotherserver.org > DocumentRoot ..... > ..... > </VirtualHost> > config> edit config vhost www.someotherserver.org > password>..... > config-edit> documentroot /some/different/directory > config-edit> save exit > config> show stats vhost www.someotherserver.org > ...... > config> save sql sqlhost.server.org > config> save file /usr/local/etc/httpd.conf > config> exit > > > With this type of interface to the _running_ configuration of the > server, everyone here can go out and create whatever GUI they wish. > It only needs to speak the language of this interface. It offers > other benefits such as realtime syntax checking, access to running > configuration info, debugging capability, etc. server config like this isnt cant do anything that cant be done on a Unix client with an expect script. (the expect script actually telnets over modifies the source/restarts the daemon/etc... I'm not trying to completely kill this idea, but what additional functionality would this give us in creating a gui over the HTML/CGI idea (besides the fact that anyone and their dog could write their own gui for apache and modifying the config of multiple servers could be automated using scripts?) -Matt
