Re: [AOLSERVER] Exposing API's to other modules?
At 11:12 AM 1/3/2002, you wrote: >I believe nsopenssl conforms to these standards as they are written now. >The standard you pointed us to covers function naming standards, but makes >no distinction between functions in the AOLserver core versus functions in >a module. > > >/s. Hi Scott, I didn't intend to imply you weren't living these standards. I was trying to back up your point that there is value to using these naming conventions. I shall weasel by saying that I see the distinction between core vs. non-core as implicit rather than explicit. Jim and the other folks, when writing Naviserver used Ns_ and not Tcl_ so perhaps we all might have clued in to write our external modules as My_ and not Ns_ and not Tcl_. Jerry Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
Re: [AOLSERVER] Exposing API's to other modules?
I believe nsopenssl conforms to these standards as they are written now. The standard you pointed us to covers function naming standards, but makes no distinction between functions in the AOLserver core versus functions in a module. /s. > On 2002.01.03, Jerry Asher <[EMAIL PROTECTED]> wrote: > > One of Ousterhout's greater contributions was the documentation of his > > team's programming standards. I apologize for ending this message without > > the link. But if they're not there already, maybe the AOLserver.com folks > > could link to them from their site. > > http://aolserver.com/docs/devel/standards.adp > > Read it. Love it. Live it. Store it in your bedside table > next to your bible, if you're that type. Read it to your kids > at night before they go to bed. > > -- Dossy > > -- > Dossy Shiobara mail: [EMAIL PROTECTED] > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > >
Re: [AOLSERVER] Exposing API's to other modules?
On 2002.01.03, Jerry Asher <[EMAIL PROTECTED]> wrote: > One of Ousterhout's greater contributions was the documentation of his > team's programming standards. I apologize for ending this message without > the link. But if they're not there already, maybe the AOLserver.com folks > could link to them from their site. http://aolserver.com/docs/devel/standards.adp Read it. Love it. Live it. Store it in your bedside table next to your bible, if you're that type. Read it to your kids at night before they go to bed. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: [AOLSERVER] Exposing API's to other modules?
> One of Ousterhout's greater contributions was the documentation of his > team's programming standards. I apologize for ending this message without > the link. But if they're not there already, maybe the AOLserver.com folks > could link to them from their site. > > maybe this link? http://tcl.activestate.com/doc/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [AOLSERVER] Exposing API's to other modules?
>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. I have worked on several well built systems where, having learned the naming conventions, I could just about "make up a name to fit the functionality I was looking for" and then find that that function had already been written by the developers. One of Ousterhout's greater contributions was the documentation of his team's programming standards. I apologize for ending this message without the link. But if they're not there already, maybe the AOLserver.com folks could link to them from their site. Jerry Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
Re: [AOLSERVER] Exposing API's to other modules?
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 > > >
Re: [AOLSERVER] Exposing API's to other modules?
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
Re: [AOLSERVER] Exposing API's to other modules?
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. > > >
Re: [AOLSERVER] Exposing API's to other modules?
+-- On Dec 27, Ramin Naimi said: > Hello, > How can a module X expose API's to other modules? Hmm. I thought a module could refer to another module's exported C functions directly. Have you tried it?
