Well, the cat's out of the bag already. Let's set a standard for exposed functions that sit within modules.
Currently, in nsopenssl's case: NsOpenSSL* functions are externed but are not to be called from outside the module. Ns_OpenSSL* functions are external APIs that can be called from anywhere. All others (MakeSSLContext and such) are private to the .c file they're defined in. We can change the externals to: NsmOpenSSL* and Nsm_OpenSSL* where Nsm = Naviserver Module, and OpenSSL would be substituted for whatever the module's name is. This won't prevent name collisions between modules, but it will prevent them between a module and the core. Is this a big deal? Changing function names just to be consistent may be viewed as a waste of time. I don't happen to think so. It helps when I go read another module's sources if they follow a style consistent with the core stuff. I'm probably outnumbered in this view. /s. > In a message dated 12/28/01 12:02:35 AM, [EMAIL PROTECTED] writes: > > >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. > > > > > Hello, > > Actually, I would suggest not using the Ns_ prefix for your modules except > for the required Ns_ModuleInit and Ns_ModuleVersion. The assumption was that > Ns_ external functions are public from the AOLserver core like Tcl_ is public > from Tcl core. As long as other folks don't use Ns_ as a prefix, we only > have to watch for conflicts with the AOLserver core functions. I think > there's been some cheating in the past, e.g., some of the database drivers > used the Ns_ the prefix when they weren't in the core. Also, nsopenssl is so > popular and has the unique Ns_OpenSSL prefix it's really not a problem. > > What we do here at AOL is follow the same code style but use a different > prefix, e.g., Dci_ or Aol_ for our custom modules. > > > -Jim > > >
