The AOLserver test platform I'm building already does this for tests. When I build the platform with nsopenssl, the $TOP/tests/nsopenssl.tcl file is set up. The nsd.tcl file looks in $TOP/tests for module config files and loads the ones it finds. It also loads the .so files for modules that have a .tcl file in the tests directory.
To make this a feature of AOLserver in general, the following will need to be done: 1. Put the module config Tcl files in a more sane place. Somewhere under servers/$servername makes sense since AOLserver 4.x will be virtual server capable, and you'll probably want a separate config file for each module on a per-virtual server basis. Module dependencies would also need to be handled as some modules may need to be loaded prior to others. 2. The main nsd.tcl file will need to be altered such that it only contains the global server config params and a looping construct to start and configure each virtual server and configure the modules for each of those servers. The issue here is that only one copy of each module should (probably) be loaded regardless of how many virtual servers are defined. This means that each module will probably need to recognize what server+conn context it's in when it is being configured and when it performs a requested operation. nsopenssl, for example, will need to know what virtual server owns port 443 versus port 8443 and do the right thing (i.e. use different certs for the two ports). I would expect each module that compiled would install its own default init Tcl file into the right place, which the admin would then alter to suit their system. /s. ----- Original Message ----- From: "Tom Jackson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 03, 2002 1:30 PM Subject: [AOLSERVER] Config File Improvements > Has anyone worked on improving the default nsd.tcl file structure? For > new users, and for users wanting to try something new, the lack of > documentation and default values for the different modules makes > experimentation difficult. > So here are some random thoughts: > Move module configuration into separate files. Handle all explaination > and variable setting at the top of these files, source the module file > iff it is actually used in the main nsd.tcl file. > > Or do the same with a single file, but enclose the module sections > inside ifs conditioned on whether the module is used. > > My overall impression is that some solution that allowed the developer > to concentrate on the top part of the file for setting well named, and > maybe commented, variables would be much easier to setup and maintain. > > --Tom Jackson > >
