Forum OpenACS Q&A: Response to nsjava staus

68: Response to nsjava staus (response to 1)
Posted by John Sequeira on

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.