For C modules, simply create the C functions you want exposed from your module as externs and call them Ns_SomeName. Just make sure you don't conflict with a C function name that already exists in the core or in other modules. You do this by prepending something that you think is going to be unique. For the nsopenssl module, I've named all externally visible functions as "Ns_OpenSSL*, where '*' is whatever you choose.
For the calling C module, I think you'll probably want to have func prototypes declared in your module for the C funcs in the other module that you're calling, otherwise your module's compilation will complain. If your module is using C functions from the core AOLserver C API, your module will already see the func prototypes via the include/ns.h file. As long as all C modules are loaded before any of them call the C functions of other modules (which is what should happen; just don't put any of these calls in your Ns_ModuleInit function) you should be ok. For Tcl, if your procs are loaded at server start time then they are visible to all Tcl interps created to handle conns, scheduled things etc. /s. > Hello, > How can a module X expose API's to other modules? > I can think of the following possiblities: > A) Add Tcl commands, so the other modules could execute the commands > B) Register for URL(s), maybe one URL with parameters for which function and > the function parameters encoded in the URL, or multiple URL's, one for each > function being exposed > C) User modules would load module X (e.g. in Win32 calling LoadLibrary) and > calling the exposed functions > > Is there any other way? I suppose the cleanest of them all is choice A. Is > there an equivalent method but for C API's (in other words, can a module add > C functions to be available to other modules to call directly, e.g. through > some Ns_Call (funcname, ...) call)? > > Thanks, > Ramin. > > >
