Hi everybody! The new ns_moduleload command seems to add some confusion to what is being done on the virtual server/interp initialization, unfortunately.
In the way it works now, modules are loaded from the virtual server initialization script. At that time the new ns_moduleload is used to load the module (and invoke its Ns_ModuleInit call). In the way it worked before, modules were loaded by the core *before* the script got executed. This has a very fine, yet problematic side effect (which is BTW hitting me very hard): If I place some Tcl commands in a module and would like to use those commands in the server init script I'm out of luck :-( By coding my modules to use Ns_TclInitInterps() I was simply adding a callback to be run each time an interp was created for the thread. Now, during the startup when the virtual server scripts are executed, the modules were loaded by the server, and hence available in the interp which was runnign the init script. This is because a new interp was created and inited before the script was run. Now, the init script itself loads the module, the module does register that callback but this is activated way later, (for other interps, threads) hence my init scripts break. I would not like to recompile all my modules. Even more, it might be even impossible to do that because of the existing field installations. So I have a serious backwards compatibility problem. Ah... just of curiousity, I inspected the nslog module and there you go: the same thing is happening. This module adds new Tcl command [ns_accesslog] which is inaccessible during the evaluation of the virtual interp init script, ALTHOUGH the module has been loaded with the ns_moduleload BEFORE this command is used for the first time. I believe we will have to reconsider the usage of ns_moduleload mechanism ... Otherwise, what are my options? Cheers, Zoran
