On Tue, 24 Jun 1997, Pierre-Yves Kerembellec wrote:
>Just my 2 cents for this GUI :
I've deleted quite a bit of the message for brevity.
> * first, I think we all agree on the fact that the GUI should
> be WEB-based (since a protocol exists, why should we developp
> something new again and again ?), even if emerging ideas (such
> as telnet-based interface) should also be taken in account (but
> it's the underlaying protocol IMHO)
>
> (1) : Web-based
Web-based front-ends do not rule-out a telnet driven back-end
API.
> * fourth, the fonctionnalities : an adminitsrator should be able to
> change any basic parameters in the server (adress, port, alias,
> scriptalias, ) ... versatile parameters which are module-dependant
> should be obtained via the 'info module' and passed as-is to the GUI
> as text ...
>
> (4) : basic parameters settings + admin actions such as start, stop,
> reload
I disagree. I think we can build a list of directives, and
create a simple interface to add directives. If you look at
what a directive is made up of you get (basically):
directive name
number of arguments
scope (whole server, per-directory, virtualhost, etc.)
> * fifth, the programming language : the one which is the most portable
> today is obviously C; perl, python, java, C++ ... need prerequisite
> installations
>
> (5) : have it done in C
Personally, I'd lean towards coding it in perl, but that's
just a general preference. Again, if we use the telnet server
backend, people can use whatever languages they like to make
frontends.
The way I see it, the best way would be to have the server
(preferably telnet reachable) control the configuration, and
store the configuration in whatever internal format it likes
(dbm, sql, whatever) but have a command to generate standard
apache configuration files from that internal data. At that
point, it just a matter of using the interface to switch
around the values, regenerate the conf files, and kickstart
the server.
-Mark
