AOLserver Wiki - User contributions [en]

Module inclusion

2008-04-16T19:36:11Z

Rcobb: /* Configuring a binary or combined binary & Tcl module into your server */

Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are included into your runtime using a section of the [[AOLServer Configuration]] file.
== Configuring a binary or combined binary & Tcl module into your server ==
As documented [http://aolserver.com/docs/devel/c/ in the AOLServer C Developer's Guide], a binary module is a dynamically loadable library (.so or .dll) that will be linked into the server at startup. To get AOLServer to try to link it in:
# Put the file in the right directory:
#* In the default configuration of AOLServer, the right place is usually {your installation directory}/bin (e.g., /usr/local/aolserver/lib). In the AOLServer configuration file, by convention, this directory name is written as "${bindir}". Some installations use a separate "${homedir}/lib" (thus ${libdir}) directory.
#* (In AOLServer 3.x and below, the convention for the extension for dynamic libraries was to follow the convention of the host operating system; e.g., for Linux/Unix to use ".so" and for Windows to use ".dll". In AOLServer 4.0 and above, we just use ".so" for all dynamic libraries to simplify the configuration and packaging).
# Tell AOLServer that it should provide that module to the virtual servers you're configuring.
#* In the modules section associated with your virtual server (e.g., "ns/servers/${servername}/modules" in nsd.tcl), add the library using the syntax:
#*:<code>ns_param ''moduleName'' ''locationOfDynamicLibrary?(startupFunction)?''</code>
#: For example:
#:<pre><nowiki>ns_param nsopenssl "${bindir}/nsopenssl.so"</nowiki></pre>
# Restart your server. You should see a line that looks like
#:<pre><nowiki>[15/Apr/2008:15:39:35][31632.18446744071924766624][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so'</nowiki></pre>
Each module included into a virtual server has its own configuration ''ns_section'' in the configuration script. By convention, these sections are named "ns/servers/{servername}/module/{moduleName}", where the moduleName is taken from the ns_param used to include the library in the "modules" section. Modules usually provide some guidance about how to write this section, perhaps by providing their own "nsd.tcl" files in the module directory.

The library, of course, is only dynamically linked into the AOLServer executable ''once'' (that is the nature of dynamic linking in most operating systems). It is ''initialized'' (that is, its initialization function is called) once per virtual server it is configured into. There is no mechanism for removing a dynamically loaded module once loaded; the server must be restarted to remove that context.

If a module also contains Tcl components, those should be installed into the appropriate <code>modules/tcl/${moduleName}</code> or <code>servers/${servername}/modules/tcl/${moduleName}</code> directory (as described below). Configuring AOLServer to use the dynamic library component automatically ensures that the Tcl components will be used as well.

At initialization, all dynamic loading is done before all Tcl module initialization. Modules are loaded in the order they are listed in the modules section of the configuration file.

Since the dynamic loading is done before Tcl module initialization, a convenient development pattern has emerged in the AOLServer community. A dynamically loaded module often provides some very general purpose Tcl commands; then its accompanying Tcl files are used to specialize those commands for a particular purpose. For example, an "nsldap" module may provide general LDAP interface commands, and then also provide examples, in Tcl, for using those commands to authenticate users, find their groups, etc.

=== Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) ===
Each dynamically loaded module must export (in "C" convention) an initialization function that conforms to the typedef Ns_ModuleInitProc. By convention, this startup function is named "Ns_InitProc", but if a module exports a different name, that can be accomodated in the configuration file (as shown above). Dynamically loaded modules ''should'' export an <code>int</code> variable named <code>Ns_ModuleVersion</code> that describes the version of the module.

The build system for AOLServer 4.x makes this straightforward. Define your module initialization function using any name you'd like (the following is taken from a C++ file):
<pre><nowiki>
extern "C"
{
NS_EXPORT int
Foo_ModInit(char* server, char* module)
{
...
}
}
</nowiki></pre>

Then, in the Makefile for your module, set the MODINIT variable to the name of your function:
<pre>
MODINIT = Foo_ModInit
</pre>

== Tcl Modules ==
Developing Tcl modules for use with AOLServer is just as straightforward, but have some interesting additional features: a Tcl library really can be installed only into the Tcl interpreters for a specific virtual server, and they can usually be reloaded dynamically.

The steps are the same:
# Put the library in a place AOLServer can find it.
# Tell your virtual servers they should load it at startup.
# Restart your server so they do that.

Tcl libraries are usually a set of tcl files, and so are installed into directories named after the library. The directories to use are "${homedir}/modules/tcl/${moduleName}" for libraries that any virtual server may load, or ${homedir}/servers/${servername}/modules/tcl/${moduleName}" for libraries that will only be loaded into specific virtual servers.

If the directory contains a file named "init.tcl", it will be "sourced" into Tcl interpreters before any other files in that directory.

The syntax for loading pure-Tcl library modules is:
:<code>ns_param ''moduleName'' '''Tcl'''</code>
For example:
:<pre><nowiki>ns_param nssession Tcl</nowiki></pre>
[[Category:Documentation]]

Module inclusion

2008-04-16T19:33:47Z

Rcobb: /* Tcl Modules */

Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are included into your runtime using a section of the [[AOLServer Configuration]] file.
== Configuring a binary or combined binary & Tcl module into your server ==
As documented [http://aolserver.com/docs/devel/c/ in the AOLServer C Developer's Guide], a binary module is a dynamically loadable library (.so or .dll) that will be linked into the server at startup (by the fact that it provides an external function called "Ns_ModuleInit" and an external integer called "Ns_Version"). To get AOLServer to try to link it in:
# Put the file in the right directory:
#* In the default configuration of AOLServer, the right place is usually {your installation directory}/bin (e.g., /usr/local/aolserver/lib). In the AOLServer configuration file, by convention, this directory name is written as "${bindir}". Some installations use a separate "${homedir}/lib" (thus ${libdir}) directory.
#* (In AOLServer 3.x and below, the convention for the extension for dynamic libraries was to follow the convention of the host operating system; e.g., for Linux/Unix to use ".so" and for Windows to use ".dll". In AOLServer 4.0 and above, we just use ".so" for all dynamic libraries to simplify the configuration and packaging).
# Tell AOLServer that it should provide that module to the virtual servers you're configuring.
#* In the modules section associated with your virtual server (e.g., "ns/servers/${servername}/modules" in nsd.tcl), add the library using the syntax:
#*:<code>ns_param ''moduleName'' ''locationOfDynamicLibrary?(startupFunction)?''</code>
#: For example:
#:<pre><nowiki>ns_param nsopenssl "${bindir}/nsopenssl.so"</nowiki></pre>
# Restart your server. You should see a line that looks like
#:<pre><nowiki>[15/Apr/2008:15:39:35][31632.18446744071924766624][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so'</nowiki></pre>
Each module included into a virtual server has its own configuration ''ns_section'' in the configuration script. By convention, these sections are named "ns/servers/{servername}/module/{moduleName}", where the moduleName is taken from the ns_param used to include the library in the "modules" section. Modules usually provide some guidance about how to write this section, perhaps by providing their own "nsd.tcl" files in the module directory.

The library, of course, is only dynamically linked into the AOLServer executable ''once'' (that is the nature of dynamic linking in most operating systems). It is ''initialized'' (that is, its initialization function is called) once per virtual server it is configured into. There is no mechanism for removing a dynamically loaded module once loaded; the server must be restarted to remove that context.

If a module also contains Tcl components, those should be installed into the appropriate <code>modules/tcl/${moduleName}</code> or <code>servers/${servername}/modules/tcl/${moduleName}</code> directory (as described below). Configuring AOLServer to use the dynamic library component automatically ensures that the Tcl components will be used as well.

At initialization, all dynamic loading is done before all Tcl module initialization. Modules are loaded in the order they are listed in the modules section of the configuration file.

Since the dynamic loading is done before Tcl module initialization, a convenient development pattern has emerged in the AOLServer community. A dynamically loaded module often provides some very general purpose Tcl commands; then its accompanying Tcl files are used to specialize those commands for a particular purpose. For example, an "nsldap" module may provide general LDAP interface commands, and then also provide examples, in Tcl, for using those commands to authenticate users, find their groups, etc.

=== Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) ===
Each dynamically loaded module must export (in "C" convention) an initialization function that conforms to the typedef Ns_ModuleInitProc. By convention, this startup function is named "Ns_InitProc", but if a module exports a different name, that can be accomodated in the configuration file (as shown above). Dynamically loaded modules ''should'' export an <code>int</code> variable named <code>Ns_ModuleVersion</code> that describes the version of the module.

The build system for AOLServer 4.x makes this straightforward. Define your module initialization function using any name you'd like (the following is taken from a C++ file):
<pre><nowiki>
extern "C"
{
NS_EXPORT int
Foo_ModInit(char* server, char* module)
{
...
}
}
</nowiki></pre>

Then, in the Makefile for your module, set the MODINIT variable to the name of your function:
<pre>
MODINIT = Foo_ModInit
</pre>

== Tcl Modules ==
Developing Tcl modules for use with AOLServer is just as straightforward, but have some interesting additional features: a Tcl library really can be installed only into the Tcl interpreters for a specific virtual server, and they can usually be reloaded dynamically.

The steps are the same:
# Put the library in a place AOLServer can find it.
# Tell your virtual servers they should load it at startup.
# Restart your server so they do that.

Tcl libraries are usually a set of tcl files, and so are installed into directories named after the library. The directories to use are "${homedir}/modules/tcl/${moduleName}" for libraries that any virtual server may load, or ${homedir}/servers/${servername}/modules/tcl/${moduleName}" for libraries that will only be loaded into specific virtual servers.

If the directory contains a file named "init.tcl", it will be "sourced" into Tcl interpreters before any other files in that directory.

The syntax for loading pure-Tcl library modules is:
:<code>ns_param ''moduleName'' '''Tcl'''</code>
For example:
:<pre><nowiki>ns_param nssession Tcl</nowiki></pre>
[[Category:Documentation]]

Module inclusion

2008-04-16T19:29:00Z

Rcobb: /* Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) */

Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are included into your runtime using a section of the [[AOLServer Configuration]] file.
== Configuring a binary or combined binary & Tcl module into your server ==
As documented [http://aolserver.com/docs/devel/c/ in the AOLServer C Developer's Guide], a binary module is a dynamically loadable library (.so or .dll) that will be linked into the server at startup (by the fact that it provides an external function called "Ns_ModuleInit" and an external integer called "Ns_Version"). To get AOLServer to try to link it in:
# Put the file in the right directory:
#* In the default configuration of AOLServer, the right place is usually {your installation directory}/bin (e.g., /usr/local/aolserver/lib). In the AOLServer configuration file, by convention, this directory name is written as "${bindir}". Some installations use a separate "${homedir}/lib" (thus ${libdir}) directory.
#* (In AOLServer 3.x and below, the convention for the extension for dynamic libraries was to follow the convention of the host operating system; e.g., for Linux/Unix to use ".so" and for Windows to use ".dll". In AOLServer 4.0 and above, we just use ".so" for all dynamic libraries to simplify the configuration and packaging).
# Tell AOLServer that it should provide that module to the virtual servers you're configuring.
#* In the modules section associated with your virtual server (e.g., "ns/servers/${servername}/modules" in nsd.tcl), add the library using the syntax:
#*:<code>ns_param ''moduleName'' ''locationOfDynamicLibrary?(startupFunction)?''</code>
#: For example:
#:<pre><nowiki>ns_param nsopenssl "${bindir}/nsopenssl.so"</nowiki></pre>
# Restart your server. You should see a line that looks like
#:<pre><nowiki>[15/Apr/2008:15:39:35][31632.18446744071924766624][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so'</nowiki></pre>
Each module included into a virtual server has its own configuration ''ns_section'' in the configuration script. By convention, these sections are named "ns/servers/{servername}/module/{moduleName}", where the moduleName is taken from the ns_param used to include the library in the "modules" section. Modules usually provide some guidance about how to write this section, perhaps by providing their own "nsd.tcl" files in the module directory.

The library, of course, is only dynamically linked into the AOLServer executable ''once'' (that is the nature of dynamic linking in most operating systems). It is ''initialized'' (that is, its initialization function is called) once per virtual server it is configured into. There is no mechanism for removing a dynamically loaded module once loaded; the server must be restarted to remove that context.

If a module also contains Tcl components, those should be installed into the appropriate <code>modules/tcl/${moduleName}</code> or <code>servers/${servername}/modules/tcl/${moduleName}</code> directory (as described below). Configuring AOLServer to use the dynamic library component automatically ensures that the Tcl components will be used as well.

At initialization, all dynamic loading is done before all Tcl module initialization. Modules are loaded in the order they are listed in the modules section of the configuration file.

Since the dynamic loading is done before Tcl module initialization, a convenient development pattern has emerged in the AOLServer community. A dynamically loaded module often provides some very general purpose Tcl commands; then its accompanying Tcl files are used to specialize those commands for a particular purpose. For example, an "nsldap" module may provide general LDAP interface commands, and then also provide examples, in Tcl, for using those commands to authenticate users, find their groups, etc.

=== Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) ===
Each dynamically loaded module must export (in "C" convention) an initialization function that conforms to the typedef Ns_ModuleInitProc. By convention, this startup function is named "Ns_InitProc", but if a module exports a different name, that can be accomodated in the configuration file (as shown above). Dynamically loaded modules ''should'' export an <code>int</code> variable named <code>Ns_ModuleVersion</code> that describes the version of the module.

The build system for AOLServer 4.x makes this straightforward. Define your module initialization function using any name you'd like (the following is taken from a C++ file):
<pre><nowiki>
extern "C"
{
NS_EXPORT int
Foo_ModInit(char* server, char* module)
{
...
}
}
</nowiki></pre>

Then, in the Makefile for your module, set the MODINIT variable to the name of your function:
<pre>
MODINIT = Foo_ModInit
</pre>

== Tcl Modules ==
Developing Tcl modules for use with AOLServer is just as straightforward, but have some interesting additional features: a Tcl library really can be installed only into the Tcl interpreters for a specific virtual server, and they can usually be reloaded dynamically.

The steps are the same:
# Put the library in a place AOLServer can find it.
# Tell your virtual servers they should load it at startup.
# Restart your server so they do that.

Tcl libraries are usually a set of tcl files, and so are installed into directories named after the library. The directories to use are "${homedir}/modules/tcl/${moduleName}" for libraries that any virtual server may load, or ${homedir}/servers/${servername}/modules/tcl/${moduleName}" for libraries that will only be loaded into specific virtual servers.

If the directory contains a file named "init.tcl", it will be "sourced" into Tcl interpreters before any other files in that directory.

The syntax for loading pure-Tcl library modules is:
#*:<code>ns_param ''moduleName'' '''Tcl'''</code>
#: For example:
#:<pre><nowiki>ns_param nssession Tcl</nowiki></pre>
[[Category:Documentation]]

Module inclusion

2008-04-16T19:28:23Z

Rcobb: /* Configuring a binary or combined binary & Tcl module into your server */

Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are included into your runtime using a section of the [[AOLServer Configuration]] file.
== Configuring a binary or combined binary & Tcl module into your server ==
As documented [http://aolserver.com/docs/devel/c/ in the AOLServer C Developer's Guide], a binary module is a dynamically loadable library (.so or .dll) that will be linked into the server at startup (by the fact that it provides an external function called "Ns_ModuleInit" and an external integer called "Ns_Version"). To get AOLServer to try to link it in:
# Put the file in the right directory:
#* In the default configuration of AOLServer, the right place is usually {your installation directory}/bin (e.g., /usr/local/aolserver/lib). In the AOLServer configuration file, by convention, this directory name is written as "${bindir}". Some installations use a separate "${homedir}/lib" (thus ${libdir}) directory.
#* (In AOLServer 3.x and below, the convention for the extension for dynamic libraries was to follow the convention of the host operating system; e.g., for Linux/Unix to use ".so" and for Windows to use ".dll". In AOLServer 4.0 and above, we just use ".so" for all dynamic libraries to simplify the configuration and packaging).
# Tell AOLServer that it should provide that module to the virtual servers you're configuring.
#* In the modules section associated with your virtual server (e.g., "ns/servers/${servername}/modules" in nsd.tcl), add the library using the syntax:
#*:<code>ns_param ''moduleName'' ''locationOfDynamicLibrary?(startupFunction)?''</code>
#: For example:
#:<pre><nowiki>ns_param nsopenssl "${bindir}/nsopenssl.so"</nowiki></pre>
# Restart your server. You should see a line that looks like
#:<pre><nowiki>[15/Apr/2008:15:39:35][31632.18446744071924766624][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so'</nowiki></pre>
Each module included into a virtual server has its own configuration ''ns_section'' in the configuration script. By convention, these sections are named "ns/servers/{servername}/module/{moduleName}", where the moduleName is taken from the ns_param used to include the library in the "modules" section. Modules usually provide some guidance about how to write this section, perhaps by providing their own "nsd.tcl" files in the module directory.

The library, of course, is only dynamically linked into the AOLServer executable ''once'' (that is the nature of dynamic linking in most operating systems). It is ''initialized'' (that is, its initialization function is called) once per virtual server it is configured into. There is no mechanism for removing a dynamically loaded module once loaded; the server must be restarted to remove that context.

If a module also contains Tcl components, those should be installed into the appropriate <code>modules/tcl/${moduleName}</code> or <code>servers/${servername}/modules/tcl/${moduleName}</code> directory (as described below). Configuring AOLServer to use the dynamic library component automatically ensures that the Tcl components will be used as well.

At initialization, all dynamic loading is done before all Tcl module initialization. Modules are loaded in the order they are listed in the modules section of the configuration file.

Since the dynamic loading is done before Tcl module initialization, a convenient development pattern has emerged in the AOLServer community. A dynamically loaded module often provides some very general purpose Tcl commands; then its accompanying Tcl files are used to specialize those commands for a particular purpose. For example, an "nsldap" module may provide general LDAP interface commands, and then also provide examples, in Tcl, for using those commands to authenticate users, find their groups, etc.

=== Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) ===
Each dynamically loaded module must export (in "C" convention) an initialization function that conforms to the typedef Ns_ModuleInitProc. By convention, this startup function is named "Ns_InitProc", but if a module exports a different name, that can be accomodated in the configuration file (as shown above). Dynamically loaded modules ''should'' export an <code>int</code> variable named <code>Ns_ModuleVersion</code> that describes the version of the module.

The build system for AOLServer 4.x makes this straightforward. Define your module initialization function using any name you'd like (the following is taken from a C++ file):
<pre><nowiki>
extern "C"
{
NS_EXPORT int
Foo_ModInit(char* server, char* module)
{
...
}
</nowiki></pre>

Then, in the Makefile for your module, set the MODINIT variable to the name of your function:
<pre>
MODINIT = Foo_ModInit
</pre>

== Tcl Modules ==
Developing Tcl modules for use with AOLServer is just as straightforward, but have some interesting additional features: a Tcl library really can be installed only into the Tcl interpreters for a specific virtual server, and they can usually be reloaded dynamically.

The steps are the same:
# Put the library in a place AOLServer can find it.
# Tell your virtual servers they should load it at startup.
# Restart your server so they do that.

Tcl libraries are usually a set of tcl files, and so are installed into directories named after the library. The directories to use are "${homedir}/modules/tcl/${moduleName}" for libraries that any virtual server may load, or ${homedir}/servers/${servername}/modules/tcl/${moduleName}" for libraries that will only be loaded into specific virtual servers.

If the directory contains a file named "init.tcl", it will be "sourced" into Tcl interpreters before any other files in that directory.

The syntax for loading pure-Tcl library modules is:
#*:<code>ns_param ''moduleName'' '''Tcl'''</code>
#: For example:
#:<pre><nowiki>ns_param nssession Tcl</nowiki></pre>
[[Category:Documentation]]

AOLserver Developer's Guide

2008-04-16T19:27:26Z

Rcobb:

''(Lets not split these into seperate pages until there's enough content.)''
We assume the reader is somewhat familiar with http://aolserver.com/docs/devel/c/, or its peer pages, and now is looking for more advanced development topics.
* [[AOLserver and Tcl Crash Course]] - A Programmer's Introduction (Outline)
* '''AOLserver Internals''' -- a guide to common [[data structures]], a description of the lifetimes of a [[thread]], an [[interpreter]], a [[request]], and a [[connection]]. Discussions of memory allocation. The [[Private C API]].
* '''AOLserver and Tcl''' -- Expanded conversation about integration of AOLserver and [[Tcl]]. Issues of multi-threaded Tcl; the Tcl Library; the lifecycle of a Tcl Interp including initialization, synchronization with other threads, interthread communication, and Tcl Interp cleanup and teardown. The [[Tcl API]].
* '''AOLserver and other [[languages]]''' -- a discussion of how AOLserver integrates with [[PHP]], [[Python]], [[Java]], etc. and how these language implementations differ from AOLserver Tcl's implementation

----
* '''AOLserver Configuration''' -- a walk-through of the basic steps to properly configure AOLserver, from database pools to virtual hosting.
** Here's a starter for [[Virtual Hosting]] in AOLserver 3.x and 4.x.
** [[Module inclusion]] and how your files are treated.

----
* '''AOLserver in a multi-server environment''' -- so you've outgrown one server, a discussion of AOLserver in a multi-server environment, including load balancing, clustering, session management, logging, and database replication
* '''AOLserver Development''' -- AOLserver Best Practices, including application development, emacs hacks, use of the control port, to
* '''AOLserver Troubleshooting''' -- An enumeration of known problems and suggested fixes. A discussion of narrowing down the problem, use of debuggers and other tools (commercial as well as free). Memory, how to measure and analyze memory usage.

----
* '''AOLserver Performance Tuning''' -- A discussion of measuring, profiling, and tuning AOLserver and your application

This might be a little old by now, but it's still an excellent read: [[AOLserver Tuning, Troubleshooting and Scaling]] by [[Kriston J. Rehberg]].

See also: [[nstelemtry]].

----
* '''Graphing / Charting with AOLserver''' -- Options and examples of integrating various graphing packages with AOLserver.

Options:
* [[nschartdir]], using [http://www.crystalballinc.com/vlad/software ChartDirector]
* [[nsgdchart]], using [http://www.crystalballinc.com/vlad/software GD Charts]
* [http://develop.sussdorff-roy.com:8011/tgdcharts tgdcharts]
* [http://www.infosoftglobal.com/ FusionCharts]
* [http://sourceforge.net/projects/plplot PlPlot]
* [http://www.gnuplot.info/ GNUPlot]
* [http://rubick.com:8002/openacs/graphing Competitive analysis of graphing solutions on Aolserver/OpenACS]

AOLserver Developer's Guide

2008-04-16T19:20:30Z

Rcobb:

''(Lets not split these into seperate pages until there's enough content.)''
* [[AOLserver and Tcl Crash Course]] - A Programmer's Introduction (Outline)
* '''AOLserver Internals''' -- a guide to common [[data structures]], a description of the lifetimes of a [[thread]], an [[interpreter]], a [[request]], and a [[connection]]. Discussions of memory allocation. The [[Private C API]].
* '''AOLserver and Tcl''' -- Expanded conversation about integration of AOLserver and [[Tcl]]. Issues of multi-threaded Tcl; the Tcl Library; the lifecycle of a Tcl Interp including initialization, synchronization with other threads, interthread communication, and Tcl Interp cleanup and teardown. The [[Tcl API]].
* '''AOLserver and other [[languages]]''' -- a discussion of how AOLserver integrates with [[PHP]], [[Python]], [[Java]], etc. and how these language implementations differ from AOLserver Tcl's implementation

----
* '''AOLserver Configuration''' -- a walk-through of the basic steps to properly configure AOLserver, from database pools to virtual hosting.
** Here's a starter for [[Virtual Hosting]] in AOLserver 3.x and 4.x.
** [[Module inclusion]] and how your files are treated.

----
* '''AOLserver in a multi-server environment''' -- so you've outgrown one server, a discussion of AOLserver in a multi-server environment, including load balancing, clustering, session management, logging, and database replication
* '''AOLserver Development''' -- AOLserver Best Practices, including application development, emacs hacks, use of the control port, to
* '''AOLserver Troubleshooting''' -- An enumeration of known problems and suggested fixes. A discussion of narrowing down the problem, use of debuggers and other tools (commercial as well as free). Memory, how to measure and analyze memory usage.

----
* '''AOLserver Performance Tuning''' -- A discussion of measuring, profiling, and tuning AOLserver and your application

This might be a little old by now, but it's still an excellent read: [[AOLserver Tuning, Troubleshooting and Scaling]] by [[Kriston J. Rehberg]].

See also: [[nstelemtry]].

----
* '''Graphing / Charting with AOLserver''' -- Options and examples of integrating various graphing packages with AOLserver.

Options:
* [[nschartdir]], using [http://www.crystalballinc.com/vlad/software ChartDirector]
* [[nsgdchart]], using [http://www.crystalballinc.com/vlad/software GD Charts]
* [http://develop.sussdorff-roy.com:8011/tgdcharts tgdcharts]
* [http://www.infosoftglobal.com/ FusionCharts]
* [http://sourceforge.net/projects/plplot PlPlot]
* [http://www.gnuplot.info/ GNUPlot]
* [http://rubick.com:8002/openacs/graphing Competitive analysis of graphing solutions on Aolserver/OpenACS]

Module inclusion

2008-04-16T19:19:58Z

Rcobb: Typo

Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are included into your runtime using a section of the [[AOLServer Configuration]] file.
== Configuring a binary or combined binary & Tcl module into your server ==
As documented [[somewhere else in the wiki]], a binary module is a dynamically loadable library (.so or .dll) that will be linked into the server at startup (by the fact that it provides an external function called "Ns_ModuleInit" and an external integer called "Ns_Version"). To get AOLServer to try to link it in:
# Put the file in the right directory:
#* In the default configuration of AOLServer, the right place is usually {your installation directory}/bin (e.g., /usr/local/aolserver/lib). In the AOLServer configuration file, by convention, this directory name is written as "${bindir}". Some installations use a separate "${homedir}/lib" (thus ${libdir}) directory.
#* (In AOLServer 3.x and below, the convention for the extension for dynamic libraries was to follow the convention of the host operating system; e.g., for Linux/Unix to use ".so" and for Windows to use ".dll". In AOLServer 4.0 and above, we just use ".so" for all dynamic libraries to simplify the configuration and packaging).
# Tell AOLServer that it should provide that module to the virtual servers you're configuring.
#* In the modules section associated with your virtual server (e.g., "ns/servers/${servername}/modules" in nsd.tcl), add the library using the syntax:
#*:<code>ns_param ''moduleName'' ''locationOfDynamicLibrary?(startupFunction)?''</code>
#: For example:
#:<pre><nowiki>ns_param nsopenssl "${bindir}/nsopenssl.so"</nowiki></pre>
# Restart your server. You should see a line that looks like
#:<pre><nowiki>[15/Apr/2008:15:39:35][31632.18446744071924766624][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so'</nowiki></pre>
Each module included into a virtual server has its own configuration ''ns_section'' in the configuration script. By convention, these sections are named "ns/servers/{servername}/module/{moduleName}", where the moduleName is taken from the ns_param used to include the library in the "modules" section. Modules usually provide some guidance about how to write this section, perhaps by providing their own "nsd.tcl" files in the module directory.

The library, of course, is only dynamically linked into the AOLServer executable ''once'' (that is the nature of dynamic linking in most operating systems). It is ''initialized'' (that is, its initialization function is called) once per virtual server it is configured into. There is no mechanism for removing a dynamically loaded module once loaded; the server must be restarted to remove that context.

If a module also contains Tcl components, those should be installed into the appropriate <code>modules/tcl/${moduleName}</code> or <code>servers/${servername}/modules/tcl/${moduleName}</code> directory (as described below). Configuring AOLServer to use the dynamic library component automatically ensures that the Tcl components will be used as well.

At initialization, all dynamic loading is done before all Tcl module initialization. Modules are loaded in the order they are listed in the modules section of the configuration file.

Since the dynamic loading is done before Tcl module initialization, a convenient development pattern has emerged in the AOLServer community. A dynamically loaded module often provides some very general purpose Tcl commands; then its accompanying Tcl files are used to specialize those commands for a particular purpose. For example, an "nsldap" module may provide general LDAP interface commands, and then also provide examples, in Tcl, for using those commands to authenticate users, find their groups, etc.

=== Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) ===
Each dynamically loaded module must export (in "C" convention) an initialization function that conforms to the typedef Ns_ModuleInitProc. By convention, this startup function is named "Ns_InitProc", but if a module exports a different name, that can be accomodated in the configuration file (as shown above). Dynamically loaded modules ''should'' export an <code>int</code> variable named <code>Ns_ModuleVersion</code> that describes the version of the module.

The build system for AOLServer 4.x makes this straightforward. Define your module initialization function using any name you'd like (the following is taken from a C++ file):
<pre><nowiki>
extern "C"
{
NS_EXPORT int
Foo_ModInit(char* server, char* module)
{
...
}
</nowiki></pre>

Then, in the Makefile for your module, set the MODINIT variable to the name of your function:
<pre>
MODINIT = Foo_ModInit
</pre>
== Tcl Modules ==
Developing Tcl modules for use with AOLServer is just as straightforward, but have some interesting additional features: a Tcl library really can be installed only into the Tcl interpreters for a specific virtual server, and they can usually be reloaded dynamically.

The steps are the same:
# Put the library in a place AOLServer can find it.
# Tell your virtual servers they should load it at startup.
# Restart your server so they do that.

Tcl libraries are usually a set of tcl files, and so are installed into directories named after the library. The directories to use are "${homedir}/modules/tcl/${moduleName}" for libraries that any virtual server may load, or ${homedir}/servers/${servername}/modules/tcl/${moduleName}" for libraries that will only be loaded into specific virtual servers.

If the directory contains a file named "init.tcl", it will be "sourced" into Tcl interpreters before any other files in that directory.

The syntax for loading pure-Tcl library modules is:
#*:<code>ns_param ''moduleName'' '''Tcl'''</code>
#: For example:
#:<pre><nowiki>ns_param nssession Tcl</nowiki></pre>
[[Category:Documentation]]

Module inclusion

2008-04-16T19:10:46Z

Rcobb: First draft. Needs comment & review.

Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are included into your runtime using a section of the [[AOLServer Configuration]] file.
== Configuring a binary or combined binary & Tcl module into your server ==
As documented [[somewhere else in the wiki]], a binary module is a dynamically loadable library (.so or .dll) that will be linked into the server at startup (by the fact that it provides an external function called "Ns_ModuleInit" and an external integer called "Ns_Version"). To get AOLServer to try to link it in:
# Put the file in the right directory:
#* In the default configuration of AOLServer, the right place is usually {your installation directory}/bin (e.g., /usr/local/aolserver/lib). In the AOLServer configuration file, by convention, this directory name is written as "${bindir}". Some installations use a separate "${homedir}/lib" (thus ${libdir}) directory.
#* (In AOLServer 3.x and below, the convention for the extension for dynamic libraries was to follow the convention of the host operating system; e.g., for Linux/Unix to use ".so" and for Windows to use ".dll". In AOLServer 4.0 and above, we just use ".so" for all dynamic libraries to simplify the configuration and packaging).
# Tell AOLServer that it should provide that module to the virtual servers you're configuring.
#* In the modules section associated with your virtual server (e.g., "ns/server/${servername}/modules" in nsd.tcl), add the library using the syntax:
#*:<code>ns_param ''moduleName'' ''locationOfDynamicLibrary?(startupFunction)?''</code>
#: For example:
#:<pre><nowiki>ns_param nsopenssl "${bindir}/nsopenssl.so"</nowiki></pre>
# Restart your server. You should see a line that looks like
#:<pre><nowiki>[15/Apr/2008:15:39:35][31632.18446744071924766624][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so'</nowiki></pre>
Each module included into a virtual server has its own configuration ''ns_section'' in the configuration script. By convention, these sections are named "ns/server/{servername}/module/{moduleName}", where the moduleName is taken from the ns_param used to include the library in the "modules" section. Modules usually provide some guidance about how to write this section, perhaps by providing their own "nsd.tcl" files in the module directory.

The library, of course, is only dynamically linked into the AOLServer executable ''once'' (that is the nature of dynamic linking in most operating systems). It is ''initialized'' (that is, its initialization function is called) once per virtual server it is configured into. There is no mechanism for removing a dynamically loaded module once loaded; the server must be restarted to remove that context.

If a module also contains Tcl components, those should be installed into the appropriate <code>modules/tcl/${moduleName}</code> or <code>servers/${servername}/modules/tcl/${moduleName}</code> directory (as described below). Configuring AOLServer to use the dynamic library component automatically ensures that the Tcl components will be used as well.

At initialization, all dynamic loading is done before all Tcl module initialization. Modules are loaded in the order they are listed in the modules section of the configuration file.

Since the dynamic loading is done before Tcl module initialization, a convenient development pattern has emerged in the AOLServer community. A dynamically loaded module often provides some very general purpose Tcl commands; then its accompanying Tcl files are used to specialize those commands for a particular purpose. For example, an "nsldap" module may provide general LDAP interface commands, and then also provide examples, in Tcl, for using those commands to authenticate users, find their groups, etc.

=== Startup Functions & Version Constraints (Ns_ModuleInit and Ns_ModuleVersion) ===
Each dynamically loaded module must export (in "C" convention) an initialization function that conforms to the typedef Ns_ModuleInitProc. By convention, this startup function is named "Ns_InitProc", but if a module exports a different name, that can be accomodated in the configuration file (as shown above). Dynamically loaded modules ''should'' export an <code>int</code> variable named <code>Ns_ModuleVersion</code> that describes the version of the module.

The build system for AOLServer 4.x makes this straightforward. Define your module initialization function using any name you'd like (the following is taken from a C++ file):
<pre><nowiki>
extern "C"
{
NS_EXPORT int
Foo_ModInit(char* server, char* module)
{
...
}
</nowiki></pre>

Then, in the Makefile for your module, set the MODINIT variable to the name of your function:
<pre>
MODINIT = Foo_ModInit
</pre>
== Tcl Modules ==
Developing Tcl modules for use with AOLServer is just as straightforward, but have some interesting additional features: a Tcl library really can be installed only into the Tcl interpreters for a specific virtual server, and they can usually be reloaded dynamically.

The steps are the same:
# Put the library in a place AOLServer can find it.
# Tell your virtual servers they should load it at startup.
# Restart your server so they do that.

Tcl libraries are usually a set of tcl files, and so are installed into directories named after the library. The directories to use are "${homedir}/modules/tcl/${moduleName}" for libraries that any virtual server may load, or ${homedir}/servers/${servername}/modules/tcl/${moduleName}" for libraries that will only be loaded into specific virtual servers.

If the directory contains a file named "init.tcl", it will be "sourced" into Tcl interpreters before any other files in that directory.

The syntax for loading pure-Tcl library modules is:
#*:<code>ns_param ''moduleName'' '''Tcl'''</code>
#: For example:
#:<pre><nowiki>ns_param nssession Tcl</nowiki></pre>
[[Category:Documentation]]

Module inclusion

2008-04-16T18:08:37Z

Rcobb: New page: Typical AOLServer modules are written in either Tcl, C, or some combination of those languages (though, of course, new languages can be added via the C module interface). They are include...

AOLserver Developer's Guide

2008-04-16T17:49:06Z

Rcobb: Added link to new page I'm about to write.

''(Lets not split these into seperate pages until there's enough content.)''
* [[AOLserver and Tcl Crash Course]] - A Programmer's Introduction (Outline)
* '''AOLserver Internals''' -- a guide to common [[data structures]], a description of the lifetimes of a [[thread]], an [[interpreter]], a [[request]], and a [[connection]]. Discussions of memory allocation. The [[Private C API]].
* '''AOLserver and Tcl''' -- Expanded conversation about integration of AOLserver and [[Tcl]]. Issues of multi-threaded Tcl; the Tcl Library; the lifecycle of a Tcl Interp including initialization, synchronization with other threads, interthread communication, and Tcl Interp cleanup and teardown. The [[Tcl API]].
* '''AOLserver and other [[languages]]''' -- a discussion of how AOLserver integrates with [[PHP]], [[Python]], [[Java]], etc. and how these language implementations differ from AOLserver Tcl's implementation

----
* '''AOLserver Configuration''' -- a walk-through of the basic steps to properly configure AOLserver, from database pools to virtual hosting.

** Here's a starter for [[Virtual Hosting]] in AOLserver 3.x and 4.x.
** [[Module inclusion]] and how your files are treated.

----
* '''AOLserver in a multi-server environment''' -- so you've outgrown one server, a discussion of AOLserver in a multi-server environment, including load balancing, clustering, session management, logging, and database replication
* '''AOLserver Development''' -- AOLserver Best Practices, including application development, emacs hacks, use of the control port, to
* '''AOLserver Troubleshooting''' -- An enumeration of known problems and suggested fixes. A discussion of narrowing down the problem, use of debuggers and other tools (commercial as well as free). Memory, how to measure and analyze memory usage.

----
* '''AOLserver Performance Tuning''' -- A discussion of measuring, profiling, and tuning AOLserver and your application

This might be a little old by now, but it's still an excellent read: [[AOLserver Tuning, Troubleshooting and Scaling]] by [[Kriston J. Rehberg]].

See also: [[nstelemtry]].

----
* '''Graphing / Charting with AOLserver''' -- Options and examples of integrating various graphing packages with AOLserver.

Options:
* [[nschartdir]], using [http://www.crystalballinc.com/vlad/software ChartDirector]
* [[nsgdchart]], using [http://www.crystalballinc.com/vlad/software GD Charts]
* [http://develop.sussdorff-roy.com:8011/tgdcharts tgdcharts]
* [http://www.infosoftglobal.com/ FusionCharts]
* [http://sourceforge.net/projects/plplot PlPlot]
* [http://www.gnuplot.info/ GNUPlot]
* [http://rubick.com:8002/openacs/graphing Competitive analysis of graphing solutions on Aolserver/OpenACS]

Ns writecontent

2008-04-11T01:20:23Z

Rcobb: Filled in the basics from reading the code.

<manpage>ns_writecontent</manpage>

'''NAME'''

: ns_writecontent - write content of request to Tcl channel

'''SYNOPSIS'''

: '''ns_writecontent''' ''?conn?'' ''channel''

'''DESCRIPTION'''

: ns_writecontent is identical to [[ns_conncptofp]]. It reads the content body of the conn (HTTP request) and copies it to the given Tcl I/O channel.

'''EXAMPLES'''

@@COMMAND_EXAMPLES@@

'''SEE ALSO'''

: ns_conncptofp

'''NOTES'''
:* Throws the error "could not copy content (likely client disconnect)" if sufficient (based on content-length) content can not be read.

[[Category:Core Tcl API]]

Ns conncptofp

2008-04-11T01:17:12Z

Rcobb: Wrote a draft of the page based on reading the code. Have not tried to generate examples.

<manpage>ns_conncptofp</manpage>

'''NAME'''

: ns_conncptofp - write content of request to Tcl channel

'''SYNOPSIS'''

: '''ns_conncptofp''' ''?conn?'' ''channel''

'''DESCRIPTION'''

: ns_conncptofp is identical to [[ns_writecontent]]. It reads the content body of the conn (HTTP request) and copies it to the given Tcl I/O channel.

'''EXAMPLES'''

@@COMMAND_EXAMPLES@@

'''SEE ALSO'''

: ns_writecontent

'''NOTES'''
:* Throws the error "could not copy content (likely client disconnect)" if sufficient (based on content-length) content can not be read.

[[Category:Core Tcl API]]

Ns formvalueput

2008-02-21T19:19:14Z

Rcobb: Added man page link as in the template / conventions, though it's a dead link.

Man page: http://aolserver.com/docs/tcl/ns_formvalueput.html

----

'''NAME'''

: ns_formvalueput - Sets the value of input elements in HTML documents

'''SYNOPSIS'''

: '''ns_formvalueput''' ''htmlpiece'' ''dataname'' ''datavalue''

'''DESCRIPTION'''

: This command sets the value of an HTML input element with NAME=''dataname'' (of any type) to the given ''datavalue''. In the following descriptions, all attribute names are handled in case-insensitive fashion (as required by HTML)
: The elements (tags) & types supported are:
:* INPUT
::;image: ignored
::;submit: ignored
::;reset: ignored
::;checkbox: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
::;radio: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
:* TEXTAREA
::If the NAME attribute matches the ''dataname'', all the enclosed text up to the next <nowiki></textarea></nowiki> tag will be replaced by the ''datavalue''.
:* SELECT
::If the NAME attribute of the SELECT tag matches the ''dataname'', this will find the first enclosed OPTION tag with a VALUE attribute that matches ''datavalue'', and set its SELECTED attribute. All other enclosed OPTION tags will have their SELECTED attribute removed.

'''EXAMPLES'''

:Check box "a" from the set a, b:
<pre><nowiki>
% set checks {<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
}
<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>

% ns_formvalueput $checks ex a
<form>
<input type="checkbox" name="ex" value="a" CHECKED>a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
</nowiki></pre>

: Set the value of hidden form field "foo" to "bar"

<pre><nowiki>
% set hidden {<input type="hidden" name="foo">}
<input type="hidden" name="foo">

% ns_formvalueput $hidden foo bar
<input type="hidden" name="foo" value="bar">
</nowiki></pre>

: Set the value of textarea "textarea" to "new value":

<pre><nowiki>
% set ta {<form>
<textarea name=textarea>Old value</textarea>
</form>}
<form>
<textarea name=textarea>Old value</textarea>
</form>

% ns_formvalueput $ta textarea {new value}
<form>
<textarea name=textarea>new value</textarea>
</form>
</nowiki></pre>

'''NOTES'''
:In AOLServer 4.5.0 (and all previous versions):
:* Checkboxes are treated exactly like radio buttons. That is, all other boxes with the same name are unchecked.
:* There is no mechanism for explicitly unchecking a checkbox.
:* In part because [[ns_tagelement]] does not strip single quotes from attribute values, the type, name, and value attribute values for each element must be either bare or enclosed by double quotes.
:* [[Ns_formvalueput]] cannot be used with well-formed XHTML 1.0 documents, nor will it create them:
:** The CHECKED and SELECTED attributes are minimized (i.e., have no value) and are always in upper case.
:** <nowiki><input></nowiki> elements encoded using the XML syntax <nowiki><input </nowiki>'''/>''' will cause syntax errors in the output (the value attribute is inserted between the trailing '''/''' and the trailing '''>''').

----

[[Category Documentation]] - [[Category Core Tcl API]]

Ns tagelement

2008-02-08T21:58:25Z

Rcobb: Confirmed the long-speculated bug.

Man page: http://aolserver.com/docs/tcl/ns_tagelement.html

----

'''NAME'''

: ns_tagelement - Find the value of an attribute in an HTML element.

'''SYNOPSIS'''

: '''ns_tagelement''' ''tag attribute''

'''DESCRIPTION'''

: This command takes a string containing an HTML element, ''tag'', and searches it for the specified ''attribute''. If the attribute is found, its value is returned. If the attribute is not found, an empty string is returned. If the attribute's value is surrounded by double quotes, they will be removed.

'''EXAMPLES'''

<pre>
% set tag {<img height=150 border="0" class="c1 c2" src='me.jpg'>}
<img height=150 border="0" class="c1 c2" src='me.jpg'>

% ns_tagelement $tag id

% ns_tagelement $tag border
150

% ns_tagelement $tag class
c1 c2

% ns_tagelement $tag src
'me.jpg'
</pre>

'''NOTES'''

: Is not removing single quotes surrounding the value a bug?
:* [[User:Rcobb|Rick Cobb]] 16:58, 8 February 2008 (EST): Yes. See [[ns_formvalueput]]

'''SEE ALSO'''

: [[ns_tagelementset]]

----

[[Category Documentation]] - [[Category Core Tcl API]]

Ns formvalueput

2008-02-08T21:55:45Z

Rcobb: typo

Man page: '''not in source tree'''

----

'''NAME'''

: ns_formvalueput - Sets the value of input elements in HTML documents

'''SYNOPSIS'''

: '''ns_formvalueput''' ''htmlpiece'' ''dataname'' ''datavalue''

'''DESCRIPTION'''

: This command sets the value of an HTML input element with NAME=''dataname'' (of any type) to the given ''datavalue''. In the following descriptions, all attribute names are handled in case-insensitive fashion (as required by HTML)
: The elements (tags) & types supported are:
:* INPUT
::;image: ignored
::;submit: ignored
::;reset: ignored
::;checkbox: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
::;radio: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
:* TEXTAREA
::If the NAME attribute matches the ''dataname'', all the enclosed text up to the next <nowiki></textarea></nowiki> tag will be replaced by the ''datavalue''.
:* SELECT
::If the NAME attribute of the SELECT tag matches the ''dataname'', this will find the first enclosed OPTION tag with a VALUE attribute that matches ''datavalue'', and set its SELECTED attribute. All other enclosed OPTION tags will have their SELECTED attribute removed.

'''EXAMPLES'''

:Check box "a" from the set a, b:
<pre><nowiki>
% set checks {<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
}
<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>

% ns_formvalueput $checks ex a
<form>
<input type="checkbox" name="ex" value="a" CHECKED>a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
</nowiki></pre>

: Set the value of hidden form field "foo" to "bar"

<pre><nowiki>
% set hidden {<input type="hidden" name="foo">}
<input type="hidden" name="foo">

% ns_formvalueput $hidden foo bar
<input type="hidden" name="foo" value="bar">
</nowiki></pre>

: Set the value of textarea "textarea" to "new value":

<pre><nowiki>
% set ta {<form>
<textarea name=textarea>Old value</textarea>
</form>}
<form>
<textarea name=textarea>Old value</textarea>
</form>

% ns_formvalueput $ta textarea {new value}
<form>
<textarea name=textarea>new value</textarea>
</form>
</nowiki></pre>

'''NOTES'''
:In AOLServer 4.5.0 (and all previous versions):
:* Checkboxes are treated exactly like radio buttons. That is, all other boxes with the same name are unchecked.
:* There is no mechanism for explicitly unchecking a checkbox.
:* In part because [[ns_tagelement]] does not strip single quotes from attribute values, the type, name, and value attribute values for each element must be either bare or enclosed by double quotes.
:* [[Ns_formvalueput]] cannot be used with well-formed XHTML 1.0 documents, nor will it create them:
:** The CHECKED and SELECTED attributes are minimized (i.e., have no value) and are always in upper case.
:** <nowiki><input></nowiki> elements encoded using the XML syntax <nowiki><input </nowiki>'''/>''' will cause syntax errors in the output (the value attribute is inserted between the trailing '''/''' and the trailing '''>''').

----

[[Category Documentation]] - [[Category Core Tcl API]]

Ns formvalueput

2008-02-08T21:54:48Z

Rcobb: OK, I think it's correct now :-)

Man page: '''not in source tree'''

----

'''NAME'''

: ns_formvalueput - Sets the value of input elements in HTML documents

'''SYNOPSIS'''

: '''ns_formvalueput''' ''htmlpiece'' ''dataname'' ''datavalue''

'''DESCRIPTION'''

: This command sets the value of an HTML input element with NAME=''dataname'' (of any type) to the given ''datavalue''. In the following descriptions, all attribute names are handled in case-insensitive fashion (as required by HTML)
: The elements (tags) & types supported are:
:* INPUT
::;image: ignored
::;submit: ignored
::;reset: ignored
::;checkbox: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
::;radio: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
:* TEXTAREA
::If the NAME attribute matches the ''dataname'', all the enclosed text up to the next <nowiki></textarea></nowiki> tag will be replaced by the ''datavalue''.
:* SELECT
::If the NAME attribute of the SELECT tag matches the ''dataname'', this will find the first enclosed OPTION tag with a VALUE attribute that matches ''datavalue'', and set its SELECTED attribute. All other enclosed OPTION tags will have their SELECTED attribute removed.

'''EXAMPLES'''

:Check box "a" from the set a, b:
<pre><nowiki>
% set checks {<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
}
<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>

% ns_formvalueput $checks ex a
<form>
<input type="checkbox" name="ex" value="a" CHECKED>a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
</nowiki></pre>

: Set the value of hidden form field "foo" to "bar"

<pre><nowiki>
% set hidden {<input type="hidden" name="foo">}
<input type="hidden" name="foo"/>

% ns_formvalueput $hidden foo bar
<input type="hidden" name="foo" value="bar">
</nowiki></pre>

: Set the value of textarea "textarea" to "new value":

<pre><nowiki>
% set ta {<form>
<textarea name=textarea>Old value</textarea>
</form>}
<form>
<textarea name=textarea>Old value</textarea>
</form>

% ns_formvalueput $ta textarea {new value}
<form>
<textarea name=textarea>new value</textarea>
</form>
</nowiki></pre>

'''NOTES'''
:In AOLServer 4.5.0 (and all previous versions):
:* Checkboxes are treated exactly like radio buttons. That is, all other boxes with the same name are unchecked.
:* There is no mechanism for explicitly unchecking a checkbox.
:* In part because [[ns_tagelement]] does not strip single quotes from attribute values, the type, name, and value attribute values for each element must be either bare or enclosed by double quotes.
:* [[Ns_formvalueput]] cannot be used with well-formed XHTML 1.0 documents, nor will it create them:
:** The CHECKED and SELECTED attributes are minimized (i.e., have no value) and are always in upper case.
:** <nowiki><input></nowiki> elements encoded using the XML syntax <nowiki><input </nowiki>'''/>''' will cause syntax errors in the output (the value attribute is inserted between the trailing '''/''' and the trailing '''>''').

----

[[Category Documentation]] - [[Category Core Tcl API]]

Ns formvalueput

2008-02-08T21:44:31Z

Rcobb: Added examples. Noted a bunch of bugs. Will annotate ns_tagelement too.

Man page: '''not in source tree'''

----

'''NAME'''

: ns_formvalueput - Sets the value of input elements in HTML documents

'''SYNOPSIS'''

: '''ns_formvalueput''' ''htmlpiece'' ''dataname'' ''datavalue''

'''DESCRIPTION'''

: This command sets the value of an HTML input element with NAME=''dataname'' (of any type) to the given ''datavalue''. In the following descriptions, all attribute names are handled in case-insensitive fashion (as required by HTML)
: The elements (tags) & types supported are:
:* INPUT
::;image: ignored
::;submit: ignored
::;reset: ignored
::;checkbox: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
::;radio: will be checked if the NAME attribute matches the ''dataname'' (case insensitive) and the VALUE attribute matches the ''datavalue'' (case-sensitive)
:* TEXTAREA
::If the NAME attribute matches the ''dataname'', all the enclosed text up to the next <nowiki></textarea></nowiki> tag will be replaced by the ''datavalue''.
:* SELECT
::If the NAME attribute of the SELECT tag matches the ''dataname'', this will find the first enclosed OPTION tag with a VALUE attribute that matches ''datavalue'', and set its SELECTED attribute. All other enclosed OPTION tags will have their SELECTED attribute removed.

'''EXAMPLES'''
Check box "a" from the set a, b:
<pre><nowiki>
% set checks {<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>
}
<form>
<input type="checkbox" name="ex" value="a">a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>

% ns_formvalueput $checks ex a
<form>
<input type="checkbox" name="ex" value="a" CHECKED>a</input>
<input type="checkbox" name="ex" value="b">b</input>
</form>]
</nowiki></pre>
Set the value of hidden form field "foo" to "bar"
<pre><nowiki>
% set hidden {<input type="hidden" name="foo">}
<input type="hidden" name="foo"/>

% ns_formvalueput $hidden foo bar
<input type="hidden" name="foo" value="bar">
</nowiki></pre>
Set the value of textarea "textarea" to "new value":
<pre><nowiki>
% set ta {<form>
<textarea name=textarea>Old value</textarea>
</form>}
<form>
<textarea name=textarea>Old value</textarea>
</form>

% ns_formvalueput $ta textarea {new value}
<form>
<textarea name=textarea>new value</textarea>
</form>
</nowiki></pre>

'''NOTES'''
In AOLServer 4.5.0 (and all previous versions):
* Checkboxes are treated exactly like radio buttons. That is, all other boxes with the same name are unchecked.
* There is no mechanism for explicitly unchecking a checkbox.
* In part because [[ns_tagelement]] does not strip single quotes from attribute values, the type, name, and value attribute values for each element must be either bare or enclosed by double quotes.
* [[Ns_formvalueput]] cannot be used with or to create well-formed XHTML 1.0 documents:
** The CHECKED and SELECTED attributes are minimized (i.e., have no value) and are always in upper case.
** <nowiki><input></nowiki> elements encoded using the XML syntax <nowiki><input </nowiki>'''/>''' will cause syntax errors in the output.

----

[[Category Documentation]] - [[Category Core Tcl API]]

Ns formvalueput

2008-02-08T19:09:29Z

Rcobb: Oops. Testing examples found problems. THere will be more edits.

Ns formvalueput

2008-02-08T19:02:27Z

Rcobb: Fixed typo

Ns formvalueput

2008-02-08T19:01:44Z

Rcobb: Framed the page in, documented what I could. Needs examples.

Ns hrefs

2008-02-08T18:21:53Z

Rcobb: Missed a space in the indenting fix.

Man page: http://aolserver.com/docs/tcl/ns_hrefs.html

----

'''NAME'''

: ns_hrefs - Returns URLs from anchor elements in a chunk of HTML

'''SYNOPSIS'''

: '''ns_hrefs''' ''html''

'''DESCRIPTION'''

: This command finds the anchor elements (<A>) in a chunk of HTML, ''html'', and returns a list of the URLs in those elements' href attributes.

'''EXAMPLES'''
<pre><nowiki>
% set html {One good website is <A href='http://google.com/'>Google</A>.
Another is <a href='http://www.yahoo.com'>Yahoo!</a>}

% ns_hrefs $html
http://google.com/ http://www.yahoo.com
</nowiki></pre>

----

[[Category Documentation]] - [[Category Core Tcl API]]

Ns hrefs

2008-02-08T18:21:15Z

Rcobb: Made the wiki not interpret the HTTP URLs in the example; removed the question about how to do that., indented like examples in ns_http

User:Rcobb

2007-12-05T03:53:33Z

Rcobb:

Rick Cobb is System Architect @ [http://www.knownow.com KnowNow]. KnowNow's Enterprise Syndication Server, available in both hosted and installed editions, is based on AOLServer, plus a large number of added C++, Tcl, Javascript, .NET, and Java components (some installed into AOLServer, many not).

Talk:Ns url2file

2007-12-05T03:43:53Z

Rcobb: What happens to special characters?

== What happens to special characters? ==

If the url contains, e.g., the '+' character or the sequence '%20', does ns_url2file unencode it the same as the underlying page finding code does?

In AOLServer 3.4.2, it doesn't look like it does. Say I request the url '/foo%20bar.html'. If I use a Tcl library function as a "404" handler (using the file-system-as-cache technique), and generate my file via
<pre>
set file [open "[ns_url2file $url]" w]
puts $file $content
close $file
</pre>
Then the '$url' is still Not Found on the next request. I'm getting the URL by directly reading the request header (since I'm in a redirection routine, the value of [ns_conn url] is my redirected URL, not the URL originally requested).

Thought I'd ask here since it would be nice if the wiki page got updated with the answer....

Modules

2007-08-08T19:11:47Z

Rcobb: /* Miscellaneous */

''See also: [[Toolkits]] and [[Languages]]''

''[[Jamie Rasmussen]] maintains a list of AOLserver modules tested against Windows[http://empoweringminds.spd.dcu.ie/openacs/aolserver_modules]. (Not recently updated - JR)''

== Standard Modules ==

AOLserver ships with the following modules:

* [[nscgi]] -- Standard CGI support for running external C programs, perl scripts etc.
* [[nscp]] -- Admin/debug support via a telnet like interface into a running server.
* [[nsdb]] -- The database interface, loads database specific drivers (below).
* [[nsext]] -- Communicates with external database drivers via proxy daemon.
* [[nslog]] -- Common log format or extended common log format access logging.
* [[nsperm]] -- Access control lists for groups/users, supports basic auth.
* [[nssock]] -- Standard [[socket driver]], used for HTTP requests.
* [[nsssl]] -- SSL [[socket driver]], links against proprietary RSA BSAFE library (not supplied).

== Database Drivers ==

AOLserver database drivers are either internal or external. Internal drivers are shared libraries that are loaded in-process with the webserver -- they provide the best performance. External drivers are shared libraries which are loaded by the AOLserver database proxy daemon [[nsext]], which communicates with the webserver process via sockets. The advantage of running the database driver external to the webserver is that it isolates buggy, non-threadsafe database access libraries. These days however this is largely unneccessary, and the external drivers are usually slower due to context switching overhead.

* [[nsfb]] -- Internal '''Firebird|Interbase''' driver.
* [[dqd_db2]] -- Internal '''IBM DB2''' driver (unmaintained).
* [[nsberkeleydb]] -- Internal '''BerkeleyDB''' driver.
* [[nsfreetds]] -- Internal MS '''SQL Server'''/'''Sybase''' driver.
* [[nsinformix]] -- Internal '''Informix''' driver.
* [[nsingres]] -- Internal '''Ingres r3''' driver.
* [[nsibasepd]] -- External '''Interbase''' driver.
* [[nsmysql]] -- Internal '''MySQL''' driver.
* [[nsodbc]] -- Internal '''ODBC''' driver.
* [[nsoracle]] -- Internal '''Oracle''' driver.
* [[nspostgres]] -- Internal '''PostgreSQL''' driver.
* [[nssolid]] -- Internal '''Solid''' driver.
* [[nssqlite2]] -- Internal '''SQLite v2''' driver.
* [[nssqlite3]] -- Internal '''SQLite v3''' driver.
* [[nsunixodbc]] -- Internal ODBC driver which uses the '''unixODBC''' driver.

== Encryption / Security ==

* [[nsblowfish]] -- Encrypt Tcl strings with Blowfish cypher and hex encode.
* [[nsencrypt]] -- Uses OpenSSL to encrypt using the AES, Blowfish, Cast5, IDEA and DES cyphers.
* [[nsnss]] -- New SSL [[socket driver]], links against Netscape's portable runtime (NSPR) and security services (NSS) libraries.
* [[nsopenssl]] -- SSL [[socket driver]] links against OpenSSL, and also provides client connection capabilities.
* [[nspasswd]] -- CRYPT, MD5, SMD5, SHA and SSHA hashing algorithms.
* [[nssha1]] -- AOLserver module to perform SHA1 hashes.
* [[nspam]] -- Interface to Pluggable Authentication Modules (PAM).
* [[nsdigest]] -- Access control lists for groups/users (like [[nsperm]]), supports digest authentication.
* [[nsmhash]] -- Implementation of mhash library interface to hash, hmac and keygen algorithms (MD5,SHA1, ...). Available shared with nsv_*.
* [[nsmcrypt]] -- Implementation of mcrypt library interface to crypt,decrypt algorithms (blowfish, des, ...). Available shared with nsv_*.

== Virtual Hosting ==

AOLserver 2.x and 4.x have built-in support for software or name-based [[virtual hosting]], but AOLserver 3.x does not. Hardware virtual hosting (each server on its own port or IP) is supported across all three versions.

* [[nsvhr]] -- Redirecting proxy, passes virtualy hosted requests back to standalone server.
* [[nsunix]] -- [[socket driver]] for unix domain sockets, complements '''nsvhr'''.
* Patches to nsvhr and nsunix by [[Jerry Asher]] [http://web.hollyjerry.org:16080/]
* [[nssmartvh]] -- C and Tcl based smart virtual hosting module, by [[Zoro]]
* [[vat]] -- Tcl based Vhost Abstract Template Module, by [[Tom Jackson]]
* C-based virtual hosting module [http://deadlock.et.tudelft.nl/~daniel/vhost.html]
* [[nsvirthost]]

== Charting ==

* [[nsgdchart]] -- Generate png/jpg charts using open source gd library.
* [[nschartdir]] -- Generate charts using proprietary ChartDirector library.
* [[nsgd]] -- Generate png,jpg,wbmp,gif,... images using open source gd library.
* [[nsgraph]] --
* i-no graphing module using gd library (defunct: [http://www.i-no.com/art/inochart.html])

== XML ==

* [[tDOM]] -- a Tcl extension which provides XML/XSLT functionality.
* [[nsxml]] --
* [[nsexpat]] -- Interface to Expat

== Web Services ==

* [[nssoap]] -- ''unfinnished, unsupported''
* [[nsxmlrpc]] -- XML-RPC server and client API [http://openacs.org/sdm/one-package.tcl?package_id=12]

== WebDAV ==

* [[nsdav]] -- Port of Apache's WebDAV [http://www.webdav.org/mod_dav/] support for AOLserver.
* [[nswebdav]] --
* [[tDAV]] -- A WebDAV server module that uses [[tDOM]].

== Miscellaneous ==

* [[dqd_log]] -- Makes AOLserver log to a file descriptor.
* [[dqd_threadpool]] -- Job scheduling system with Tcl interface.
* [[dqd_utils]] -- collection of half a dozen small utility procs.
* [[nsadmin]] -- Database admin/log viewing features from v2 ported to v3.
* [[nsaspell]] -- Aspell Module [http://www.crystalballinc.com/vlad/software/]
* [[nsbinarysupport]] -- Write 8bit strings to connection without translation.
* [[nscache]] -- Tcl interface to AOLserver's caching API
* [[nsclamav]] -- ClamAV Anti-Virus Interface Module [http://www.crystalballinc.com/vlad/software/]
* [[nsdci]] -- AOL's Digital City extensions (distributed cache, among other goodies) (http://code.google.com/p/nsdci/)
* [[nsdns]] -- DNS Server/Proxy Module [http://www.crystalballinc.com/vlad/software/]
* [[nsdqe]] -- Collection of utilities including caching, page counter, virtual hosting etc.
* [[nsexample]] -- An example module to help guide new module writers.
* [[nsfortune]] - Fortune like game module, uses real fortune files
* [[nsftp]] -- FTP server front end for AOLserver.
* [[nsfts]] -- Interface to Postgres full text search engine.
* [[nsimage]] -- returns sizes of various modules, implements [[ns_image]] & [[ns_pngsize]], replaces [[ns_jpegsize]] & [[ns_gifsize]]
* [[nsimap]] -- IMAP Module [http://www.crystalballinc.com/vlad/software/]
* [[nsjabber]] --
* [[nsjk2]] -- Jakarta connector
* [[nsldap]] -- LDAP client
* [[nsmaverix]] -- SMTP Proxy with anti-spam/anti-virus/whitelist/greylist/blacklist capabilities and Web interface [http://www.crystalballinc.com/vlad/software/maverix/]
* [[nsmsg]] - IPC message module for AOLserver
* [[ns_pkg]] -- Dynamic Tcl package loading.
* [[nspool]] -- Pools of sockets, pipes and external processes.
* [[nsprofile]] -- Time execution of Tcl commands.
* [[nsreturnz]] -- Gzip content encoding for dynamic requests.
* [[nsrewrite]] --
* [[nsroaming]] -- Netscape Navigator 4 Roaming Profiles.
* [[nssavi]] -- SOPHOS Anti-Virus Interface Module [http://www.crystalballinc.com/vlad/software/]
* [[nssession]] -- Session Management
* [[nssession (C module)]] -- Sessions implemented as a C module
* [[nssnmp]] -- SNMP Module [http://www.crystalballinc.com/vlad/software/]
* [[nssys]] - Unix system calls, including chmod, ioctl, fsstat, syslog, signal
* [[nstelemetry]] --
* [[nsthreadpool]] --
* [[nsuuid]] -- UUID generator module
* [[nszlib]] -- Zlib Module [http://www.crystalballinc.com/vlad/software/]
* [[nsperl]] -- Embedded Perl module (not production ready) [http://jam.sessionsnet.org/files/file?file_id=5477]

== Additional Software ==

* [[jk-voting]] -- Example DB based Voting Booth
* [http://bas.scheffers.net/aolserver/ Cache Tools], by [[Bas Scheffers]] -- I haven't worked with this or tested it in years, would like to hear from users!
* Tcl AutoLoader for AOLServer by Hal Heisler [http://www.heisler.net/hal]
* AOLserver 3.x Remote Administration Modules [http://www.scriptkitties.com/]
* HTTP Cookie Library [http://www.scriptkitties.com/]
* Simple-Templating System [http://www.oakroad.net/simple-templates/]
* [[nstest]]
* [[William Webb]] has a list of some unmaintained AOLserver software he created which may still be useful to you.
* AM.net[http://aolserver.am.net] maintains a page of AOLserver resources which includes an [[ADP]] pareser module and a module which fetches web pages.

[[Category:Documentation]]
[[Category:Modules]]

What's new in 4.5

2007-08-02T20:34:35Z

Rcobb: /* Connection Management: */

This is a partial list of new features and major changes in AOLserver 4.5 (compared to 4.0). If you know of anything that is missing, please add it.

=== Connection Management: ===

These two commands can be used together to map slow running requests to a specific pool and to set limits to avoid overload.

* New '''ns_pools''' command to map method/URL's to specific thread pools.
* New '''ns_limits''' command control the number of threads executing and/or waiting for execution by method/URL.
*'''Note:''' The new scheme does not pick up connection thread pool configurations from earlier versions of AOLServer. Please see the new example configuration files, and the documentation for [[ns_pools]] and [[ns_limits]], for instructions in upgrading your configuration.
** As of 1 August 2007, the HEAD revision contains "pools.tcl", which will handle many pre-4.5 configurations.
** There are known issues when using this feature in conjunction with virtual servers; see the SourceForge bug list (and development mailing list archive) for details.

=== I/O Features: ===

* New '''Ns_QueueWait''' API to enable event-driven callbacks in the driver thread before dispatching to pools for processing.

:The allows drivers to augment data received from the client (headers, request, content) with additional data fetched over the network (likely stored in the new Ns_Cls "connection local storage" API's) before dispatching to the connection threads. An example would be to add certain personalization data received via a web service. The rationale here is that I/O events are cheap so do those upfront instead of having expensive connection threads burdened with wasteful blocking I/O. This is a somewhat obscure and technical interface.

* Added ability to manage larger file uploads by spooling to a temporary file.

=== ADP Improvements: ===

* Added a new execution caching technique at the '''ns_adp_include''' level which allows you to save the results of execution of an included ADP and includes below that for reuse on subsequent connections up to a specified time.
* Added '''singlescript''' config option which turns ADP pages into a single script enabling syntax such as "<% foreach e $list { %> element <%= $e %> here <% } %>".
* Added output buffer improvements via new Ns_ConnFlush.
* Added automatic UTF-8 to output charset encoding.
* Added gzip output compression.
* Added streaming output in chunked-encoding format instead of the previous "response with no length" HTTP/1.0 method.
* Enhanced ADP error handling and reporting.
* Added ability to trace ADP pages. Trace output is written to the server log.

=== Other Improvements: ===

* New '''Ns_TclRegisterTrace''' API to enable callbacks at key state transition points in a much more natural way. The [[ns_ictl]] command has been updated to support script-level traces.
* New '''Ns_Task''' API designed to replace the old Ns_SockCallback API which didn't do a very good job at managing timeouts along with I/O events.
* New '''ns_returnmoved''' command to return 301 http status code and redirect to a new URL.
* New '''ns_cache''' command based on ideas from the ns_cache module. This is not backward compatible with the ns_cache module.
* New '''ns_loop_ctl''' command to monitor and manage ''for'', ''while'', and ''foreach'' loops.
* Added '''ns_ictl package''' subcommand to [[ns_ictl]] command to handle loading of Tcl packages.
* Added new '''ns_register_fastpath''' command to re-enable fastpath after a previous call to '''ns_register_proc'''.
* Added ability to access more AOLserver functionality from a tclsh (nsv_*, ns_thread, etc).
* Stack checking has returned. In a multi-threaded application like AOLserver, stack checking is important for detecting buffer overruns and deep call trees blowing your thread stack, etc.
* More detailed information when logging uncaught Tcl errors. Especially for connection threads, details of the HTTP request are logged to make diagnosing the root cause of errors easier.

What's new in 4.5

2007-08-02T20:32:07Z

Rcobb: /* Connection Management: */

This is a partial list of new features and major changes in AOLserver 4.5 (compared to 4.0). If you know of anything that is missing, please add it.

=== Connection Management: ===

These two commands can be used together to map slow running requests to a specific pool and to set limits to avoid overload.

* New '''ns_pools''' command to map method/URL's to specific thread pools.
* New '''ns_limits''' command control the number of threads executing and/or waiting for execution by method/URL.
*'''Note:''' The new scheme does not pick up connection thread pool configurations from earlier versions of AOLServer. Please see the new example configuration files, and the documentation for [[ns_pools]] and [[ns_limits]], for instructions in upgrading your configuration. There are known issues when using this feature in conjunction with virtual servers; see the SourceForge bug list (and development mailing list archive) for details.

=== I/O Features: ===

* New '''Ns_QueueWait''' API to enable event-driven callbacks in the driver thread before dispatching to pools for processing.

:The allows drivers to augment data received from the client (headers, request, content) with additional data fetched over the network (likely stored in the new Ns_Cls "connection local storage" API's) before dispatching to the connection threads. An example would be to add certain personalization data received via a web service. The rationale here is that I/O events are cheap so do those upfront instead of having expensive connection threads burdened with wasteful blocking I/O. This is a somewhat obscure and technical interface.

* Added ability to manage larger file uploads by spooling to a temporary file.

=== ADP Improvements: ===

* Added a new execution caching technique at the '''ns_adp_include''' level which allows you to save the results of execution of an included ADP and includes below that for reuse on subsequent connections up to a specified time.
* Added '''singlescript''' config option which turns ADP pages into a single script enabling syntax such as "<% foreach e $list { %> element <%= $e %> here <% } %>".
* Added output buffer improvements via new Ns_ConnFlush.
* Added automatic UTF-8 to output charset encoding.
* Added gzip output compression.
* Added streaming output in chunked-encoding format instead of the previous "response with no length" HTTP/1.0 method.
* Enhanced ADP error handling and reporting.
* Added ability to trace ADP pages. Trace output is written to the server log.

=== Other Improvements: ===

* New '''Ns_TclRegisterTrace''' API to enable callbacks at key state transition points in a much more natural way. The [[ns_ictl]] command has been updated to support script-level traces.
* New '''Ns_Task''' API designed to replace the old Ns_SockCallback API which didn't do a very good job at managing timeouts along with I/O events.
* New '''ns_returnmoved''' command to return 301 http status code and redirect to a new URL.
* New '''ns_cache''' command based on ideas from the ns_cache module. This is not backward compatible with the ns_cache module.
* New '''ns_loop_ctl''' command to monitor and manage ''for'', ''while'', and ''foreach'' loops.
* Added '''ns_ictl package''' subcommand to [[ns_ictl]] command to handle loading of Tcl packages.
* Added new '''ns_register_fastpath''' command to re-enable fastpath after a previous call to '''ns_register_proc'''.
* Added ability to access more AOLserver functionality from a tclsh (nsv_*, ns_thread, etc).
* Stack checking has returned. In a multi-threaded application like AOLserver, stack checking is important for detecting buffer overruns and deep call trees blowing your thread stack, etc.
* More detailed information when logging uncaught Tcl errors. Especially for connection threads, details of the HTTP request are logged to make diagnosing the root cause of errors easier.