You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gui-dev@apache.org by Randy Terbush <ra...@zyzzyva.com> on 1997/07/02 16:13:51 UTC
Re: GUI Handling of Modules
Some quick responses here. busy busy busy :-)
> In putting together the prototype Java interface for Apache I'm having
> some trouble coming up with a nice metaphor/system for handling
> modules. Here are the problems I see:
>
> - you don't know definitively from the configuration files what
> modules are compiled in (there may not be any tell-tale directives in
> the config files) so you'll have to either parse and use the server
> footprint spewed out by one of the server directives or force the
> administrators to manually enter some sort of info on the modules for
> the configuration server to use.
This has been disucussed as a wantlist item for 2.0 API changes.
Something that would allow modules to register their presence and
perhaps register for certain classes like Auth, Log, etc. _How_ to
do this has never developed very far. It seems that the important
information needed from a config interface point of view would be
the Directives available. I'm not sure how one would pull this off
pre-2.0 without making some guesses from the config files, or
perhaps just the output of -h. Looking at the output of -h, that is
probably your best bet.
> - once the configuration server is "module aware" you'll still need to
> modify the user interface to enable/disable the configuration of certain
> modules. This implies a setup protocol and the hiding/display of some
> dialoges based on the protocol.
Tricky it would seem. It would be nice to keep auth options in the
same interface instead of splitting them for each module.
> - finally, what's the best way to develop the configuration screens for
> the modules- parse the server footprint and dynamically generate the
> configuration dialogues based on that information, use some sort of
> preconfigured data for dynamically generating the configuration dialoges
> or just develop custom setup dialogues for all the modules and then just
> display/hide them as appropriate.
As mentioned, the -h info could give you a good starting point. It
might be possible to create a module that would give you a hook
more directly into this information so that you did not need to
parse the output.
> What are your thoughts?
>
> Justin
> seiferth@erols.com
I'm hoping to turn my attention about to this topic in the coming
week.