I don't consider the mod_aolserver approach to be the best value for the effort (time+$$$). It's not a pay-once proposition, as it will need updating every time AOLServer or Apache revs by someone proficient in C, and doesn't help you to support IIS or Apache 1.x. Ignoring these latter two webservers would be an unnecessary loss. You really should support all web servers or don't bother.
My pure tcl approach has proved challenging because of several API disconnects between nstcl and Aolserver, which I haven't been able to address in a reasonable amount of time. Once/if the issues I've hit are addressed, I think it would need less maintainence by less technical coders. On scalability, I don't believe scalability will be an issue, but Don's right to point out I have no first-hand evidence of this. As a data point, I'm currently deploying perl+fastcgi apps that I ported from mod_perl+linux to IIS at several multinationals. The app scales pretty well ... but, who knows? tcl/openacs may be a lot different without AOLServer's c routines.
So, although I still have hope for portable.nsd, I would like to put forward a possibly simpler option: have AOLServer support FastCGI directly. Then you can be assured that the openacs tcl code will run unmodified on any web server that supports cgi... the performance will be on par etc. FastCGI hasn't changed in like a decade ... so you just have one side of the API maintainance problem instead of two. And, fwiw, Zope implements IIS support this way.
Although I don't know for sure what this would entail, and it's not a one-off cost, I have to believe that tweaking AOLServer to respond to a request coming in from a socket is a smaller deal that meshing large, mostly incompatibly APIs like AolServer<->nstcl, AolServer<->ISAPI or AolServer<->Apache2.
Here's a discussion on extending AOLServer to support multiple protocols (a necessary pre-req, I suspect)
http://www.mail-archive.com/aolserver@listserv.aol.com/msg07871.html
