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 > [EMAIL PROTECTED] I'm hoping to turn my attention about to this topic in the coming week.
