Don,
You're characterizing my suggestion as dumping AOLServer. That's not really necessary. Webware, for example, supports a native apache run-mode (mod_webware), but also does CGI and FastCGI if you're not an Apache disciple or don't want to run it as a module. OpenACS could have a reference implementation in AOLServer exactly the way it does now, but by implementing future functionality in a way that minimized native AOLServer API dependencies not covered by MC's nstcl (or not easily ported to nstcl), and considering back-ports of portable code into the source tree, you could make life easy for OpenACS/FastCGI porters to keep up. This is quite similar to the whole DB-API thing, now that I think about it, but I'm pretty sure it'd be asking a lot less. Unlike data access, the vast majority of scripts do not call into non-portable AOLServer APIs, right? (Non portable as in beyond simply getting query params)
Also, for better or worse, FastCGI hasn't evolved in about 5 years, that I know of. Their external dependencies (apache., perl, tcl) have evolved, but you have a larger community committed to supporting it, and they've historically done a decent job of it. Plus the run-everywhere CGI->FastCGI bridge probably hasn't needed updating in a *long* time.
On the Windows stuff in general, communities need to be bootstrapped, to achieve critical mass and be viable - the usual catch-22. Pg/Win32, AOLServer/Win32, etc never got there. Do we need to make a community forming itself around those elements a precondition for what I expect to be a much broader acceptance and deployment of the toolkit?
You're point about it being more work is well taken. I was hoping to get some help doing the homework of how much work it would be (and I got some), but I'll go off look into it some more. My instinct is that Michael's work makes this plan doable, but we'll see.
