Andrew's right ... but there has been a paradigm shift in the OpenACS community - some of us, at least - to use Tcl APIs where possible in order to REAGAIN the ability to rapidly generate applications.
The write-the-API-in-PL/SQL works OK if all you're just using one RDBMS, but supporting both makes it a pain in the rear.
In practice it either slows down development considerably or (as is becoming all to common in our community) only one RDBMS rather than both are being supported by developers.
Also the ability to automate the generation of forms, displays, etc has been diminished in both ACS and OpenACS 4.x code by laziness - attributes aren't getting properly defined because it's tedious and time-consuming. A Tcl object definition API can automatically generate all the SQL stuff needed, including tables (the type system does this today via PL/[pg]SQL though I doubt more than 10% of our OpenACS programmers are aware of it) and attributes.
Jun - we're not talking about generating a persistent layer, just making certain things easier. As Jeff mentions, one thing we might do would be as simple as defining the type views for all objects as is already done for CR objects. Likewise autogeneration of new/delete functions (or generating the inserts in straight SQL) would end abuse of those procedures (some types do more in "new" than they should, for instance, which means you have to *look* at a type's "new" procedure to know how much it is doing and how much you have to do afterwards).
Consistency, ease of programming, the moving of tedious tasks like type attribute definitions into Tcl ... these are the kind of rapid development things we're talking about.
No more radical than the development of the recent and I believe uncontroversial developments of Tcl APIs to define service contracts or portlets for instance.
