> On Wed, 18 Jun 1997, Randy Terbush wrote: > > > Just a few points to start a discussion here: > > > > It seems that it is time that some thought go into an interface > > that is more politically correct. :-) Hopefully this list will > > allow us to come to some consensus as to what the tools/hooks > > should be to make it easy for interface developers to communicate > > with the server. > > Agreed. I think the goal should be to develop a product that it just a > easy to use, if not more so, than the interfaces that are already out > there for other httpd server software, while maintaining our Prime > directive of Cross platform compatibility.
While I agree that cross-platform compatibility would be a good goal for the interface development, I would like to reiterate that the main focus of this list should be discussion of how the various interfaces communicate with Apache to handle configuration, monitoring, etc. Coming to agreement on what the interface should be might be impossible, but hopefully we can come to some agreement on an API that Apache could provide form these interfaces. > > In previous side discussions, some of the following possibilities > > have been suggested as methods to accomplish our goals. That goal > > being a way to safely communicate configuration and status issues > > to the Apache webserver. > > > > - SNMP > > - LDAP > > - others? > > I do not know what IIS uses but I know that Netscape enterprise server has > a web front end for the majority of its configuration items. This is > generally just a httpd attached to a different port of the machine. I've toyed with standalone config servers for Apache. From my experience, there is always information that it would be nice to have from the server's point of view. Things like: * current access restrictions for the entire document space * spare server information (to allow intelligent tuning of these variables. * data transfer rates (to allow bandwidth limit tuning) * others? These types of requirements have at the very least demanded some sort of socket to the running server(s). If we could agree on SNMP or LDAP or some other protocol for communicating these things, it should allow GUI developers the ability to use things like Perl, Tcl, Java, etc. to communicate with the server. > I think it could be completely stable if we ran a seperate httpd process > all together (with stripped out config files, and only one child process) > that is attached to some port of the machine other than 80 and is > dedicated to modifying the main server config files and re-huping the > daemon. The one httpd would have to run under root and only root though.. Finding ways to do this without running as root would be desireable. LDAP may offer the ability to authenticate access. I'm rather green on LDAP, but it appears to be able to do what we need. > > > Storage of the config info could move to: > > - Berkeley DB 2.0 > > - SQL > > - others? > > I Think that part of our goal is to maintain the existing simplicity of > the apache config files (they copied the NCSA httpd config file format), > and to use this as a standard.. there is not reason why we can't just > part these files for the info we need. All our program needs to know then > is the location of the servers main httpd.conf file. This is the other reason to develop an API to the configuration of the server. There is a very good chance the the config file format will change in Apache 2.0. It would be nice to establish an API that would allow GUI developers to make the transition without great pain in file format changes.
