Forum OpenACS Q&A: Response to A Template-Based ACS
As far as Jin's comments regarding supporting more than one database, well, do keep in mind that aD has a very narrow mission, to become the dominant developer of complex database-driven web sites. Most of their potential customers use or will be using Oracle. aD is tight with Oracle. Supporting multiple databases would simply slow them down, without tangibly increasing their business and potentially putting their relationship with Oracle at risk. I suspect the latter reason's the most important, to be honest. Philip loves Oracle. Oracle bought an earlier company of his. Several months ago, when a curious individual e-mailed him about the desirability of making the ACS available on a low-cost or free database like Postgres, Philip lambasted him in his response, telling him that only "losers" would consider using anything other than Oracle. No, it wasn't me, but I did get to see the e-mail exchange...
I think aD is starting to wake up to the fact that a Postgres-based ACS might turn out to be very popular, indeed. While I don't envision ACS/PG taking over huge sites built on load-balancing server farms (the fact is that PG has zero support for this level of scalability), I do envision the ACS/PG being used to implement a large number of more modest sites. You could do something like scorecard.org using ACS/PG, for instance...
The bottom line is that any such abstraction of queries would have to come from us, would probably not be folded back into the mainstream ACS, wouldn't be maintained for new modules by aD anyway (we'd be porting to this abstraction), and the needs of ACS/PG users may not track mainstream ACS forever anyway. We have no way, at the moment, to port over Java embedded in Oracle except to rewrite it or find someone with the time to embed the JVM into Postgres ala the Tcl and Perl embedded languages - any takers? Webmail's being implemented by aD in this way, tying them even more closely to Oracle (and it's being implemented by Jin).
Jin's comments should also be considered in light of the fact that aD is apparently working on an Apache/mod_perl version (or at least is considering it). The use of AOLserver shuts them out of a fair number of potential customer sites, since Apache and Perl are both objects of religious significance to a fairly large slice of the Unix world.
This will slow aD down. Maintaining AOLserver/Tcl and Apache/mod_perl versions will be a far greater maintenance headache than trying to support a couple different dialects of SQL. More evidence in my mind that it is the relationship with Oracle, not technical considerations, that causes aD to refuse to help make the toolkit more portable in regard to the underlying RDBMS.
