Forum OpenACS Q&A: Response to Windows, AOLServer, and OACS

Apparently the module API for Apache 2 is considerably different than for Apache 1, which is why module porting of even things much more mainstream than mod_aolserver has lagged.  This is my understanding, anyway.  So porting mod_aolserver may be a considerable amount of work.

Also Apache 2 is a native Win32 app.  Can it talk to PG running inside Cygwin?

As far as supporting SQL Server ... does it have a sufficiently rich programming language to support our architecture?  One downside of aD's choice to bury so much logic in PL/SQL is that you need an RDBMS with good embedded programming language support.  PL/pgSQL was designed explicitly to give PG something similar to PL/SQL in capability.  If it weren't the ACS 4 port would've required rewriting big hunk of the toolkit as a first step.  We would've ended up with a lot more portable queries if we had but it would've taken even longer to get to where we are ...

Also supporting three RDBMSs is a somewhat intimidating notion.  We're already seeing time lags in support of new packages with just two RDBMSs.  Since Talli's involved in this discussion I'm compelled to remind him that Musea didn't port ETP to Oracle, Jon Griffin and I got stuck with that task.

A SQL Server veresion would almost certainly require some financial support from someone.  Win2K and SQL Server don't come with a "free for development" licensing model ala Oracle...

And if we complexify the project even further ... is it reasonable to expect anyone (much less me) to manage the project gratis?  This project has already taken up literally months of my time, income-free months, and while I've had success in landing OpenACS-based consulting work whenever I do the project suffers because I get pulled away from it.  If we make the project even more complex to run either more volunteer managers need to step up to the plate (this may be true even if we *don't* make it more complex) or we need to find some way to get me some subsistence funds.

On the other hand ... I stated in public many moons ago that if I were running aD, SQL Server - not PG - would be my choice as the next RDBMS to support after Oracle.  The commercial advantages are obvious even if the technical and organizational barriers are equally obvious.

Here's a first step for folks to take: do a technical evaluation of what it would take to port to SQL Server.  I'm talking queries and PL/[pg]SQL.  We did something like this for PG in the early times, marking out problems and coming up with solutions (hierarchical queries and the tree sortkey solution, for instance).

Without a detailed analysis of this sort we can't possibly begin to estimate the difficulty involved in doing a port.

For instance ... do they support the SQL standard outer join syntax as well as the old Sybase ("*=" etc) syntax?  If so, the potential work required to port queries just dropped significantly.

So on and so on ...