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
