I wanted to announce the Portable.NSD project - an attempt to rewrite OpenACS' AOLServer dependencies in pure TCL based on Michael Cleverly's nstcl library. From the project web page

The portable.nsd project will all the OpenACS source code to execute outside the AOLServer environment. We will achieve this portability be redefining the AOLServer TCL API dependencies to support different deployment containers. The container responsibility is to map AOLServer functionality to functionality offered by the environment. Deployment environment include tclsh, tclhttpd, FastCGI, and Apache 2.0 (mod_tcl and Rivet).

The AOLServer functionality we need to implement includes the tcl api, registered procs, scheduled procs, registered filters, and global state (nsv's). AOLServer initializes a single interpreter and then clones it to perform it's multithreaded request processing. Our initial approach will be to treat the application as a single-threaded one, and ignore the issue of multiple interpreters, and the separation of the initializaton and request processing. Eventually we'll figure out some way to deal with singleton initialization behavior and page serving behavior (See the Presentation for a proposed solution).

Note: Portable.nsd is not an attempt to replace AOLServer's role as OpenACS' native deployment environment. It is intended to provide viable options to prospective users constrained to web servers, operating systems, or single-threaded TCL packages not directly or sufficiently supported by AOLServer. The intention is absolutely not to fork OpenACS but to provide an emulation layer that supports 100% of the current and future OpenACS codebase.

Right now, I've implemented nsv_ and ns_config functionality as globals, and I've implemented enough of ns_xml to successfully parse xql files using tDOM. I am currently working on a pure-tcl pg_bind function.

I'm doing the bulk of my work on the bootstrap code using TclPro's visual IDE ( screenshot ), and I'm finding breakpoints and watch variables really useful. I hope my next generally useful deliverable to be a set of scripts which enable 'headless' installation (i.e. no browser required) of OpenACS.

Speaking from some bad experiences in the area, I wouldn't ignore the multi-threaded issue.  It's much easier to incorporate multi-threading from the start than it is to go back and retrofit it later.  As an example, Tclblend was originally implemented as a single-threaded app, and I ran into some really ugly problems when I tried to integrate it in with aolserver.  In the end, it turned out to be easier to rewrite the core functionality than it was to integrate tclblend with aolserver.

In any event, I can't wait to see how your work turns out.  I've always wished that I had a tclsh based interface to openacs.  This could turn out to be quite a useful tool in many respects.

To Ben and Dan,

Points taken.  I'm really encouraged that you see something useful dropping out of this.

Multithreading support is not on *my* short list,  because I mostly just want to get to Apache/IIS support quickly and I don't need it if I rely on FastCGI.  Plus ( more importantly ) it's not really in my skill set.

However,  it is both on Michael C's short list and his skill set,  because he has TclHTTPd as his primary deployment environment. If my writings about the project make it seem like your cautions aren't being heeded,  consider it my own bias creeping in.

Andy,

Thanks for the pointer.  Michael is aware of Zoran's work,  and will be using it as one of our deployment options.  The idea is you set a flag somewhere in your config file,  i.e.

DeploymentEnvironment  (mod_tcl|tclhttpd|fastcgi)

and the wrapper scripts we're writing will take care of mapping aolserver-isms into that environment.  We're targeting singlethread,  multithread and multiprocess at the same time - I'm roughing out globals-based commands just so the code runs in tclsh and Michael's doing the polishing necessary to make an alternate set of commands which will run in more demanding environments.

Also,  I should note that we certainly hope to leverage AOLServer's unbundled libraries at some point (the one's you pointed me to),  but we won't be letting AOL's release schedule slow us up.

I may be totally off-beam here, so feel free to slap me if I'm
talking nonsense, but I was under the impression that one of the
goals of AOLServer 4 was to seperate out the AOLServer
application API (libnsd) from the http server. If this is the case,
surely effort would be better spent in moving OpenACS from
nsd331+ad13 to nsd4, and looking at ways to use libnsd from
within the other environments in which we want to run OpenACS.

This is all assuming that AOLServer 4 with a seperate libnsd will
be usable "soon"...

Remember back on Aug. 28 I mentioned the AOL crew's apparent plans to refactor much of AOLserver into libraries? Well, here's another item on that from the AOLserver ChangeLog:

2002-10-14  Jim Davidson <jgdavidson@aol.com>

  * include/ns.h: 
  * nsd/config.c: 
  * nsd/tclinit.c: 
  * nsd/tclcmd.c: 
  * nsd/tclsock.c: 
  * nsd/main.c:  Added support for libnsd.so to be loaded 
  into a standard (thread enabled) tclsh or linked into a 
  custom tclsh.  Calling Ns_TclInit from a custom tclsh or 
  loading libnsd.so via the load command will add many 
  non-server AOLserver commands (e.g., adds ns_set but not 
  ns_adp_puts).

For those interested alternative web/application servers like TclHttpd and the like, another interesting little option is TWS, from D. Richard Hipp, creator of SQLite. I noticed it due to Nov. 2005 discussion on the SQLite list.