> 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..
IFF the config server is in fact separate, they could each look out for the other to make sure _both_ are running. I run over 100 separate parent server processes. I don't have a problem making sure they are running. > 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. Minor issue. > 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).. The point is, the mechanisms would change minimally. It could be much easier to add support for new directives if the communication with the server is the same. > 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) In case you joined late, at least half of the Apache project members are on this list. I don't view this as a bother. The group would prefer to see some standard interface to config since it is unlikely that one GUI will satisfy everyone's needs. That being the purpose of this list. To provide a communication channel to the Apache developers to help develop a configuration API that both the GUI developers and the Apache project can work with. [example deleted] > > 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... With exception that if this interface is at the very least getting it's info via a socket to the server, it can show you actual running config information. You are correct, it is a simple interface. That is the whole idea. I personally don't want to live in a GUI environment, but if I can help create a text based interface into server configuration that can be used by GUI developers, then we all win. > 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?) Exactly my point. > -Matt
