Forum OpenACS Q&A: Response to Article on ACS x Zope
1. Abstraction vs. Performance
I have written for my company a transactional message queue implementation dumping data directly into Oracle via OCI rather than using the AOLserver driver, and I have also written Python extensions in C and built my own ZODB-style (but with much more limited scope) Python object to Oracle interface, so I have some experience with the internals in both systems.
I tend to agree with Ben's comments about how SQL abstration leads to an unacceptable loss in performance. I am not sure outer joins have their place in an OLTP application, but here is the example I would use: if I want to insert rows in a table (for instance an order) and use the primary key for that row as a foreign key in another table (for instance a line item in an order).
In Oracle, I can use the non-standard INSERT INTO ... RETURNING syntax and make a single round trip. In PostgreSQL, I would first need to select from a sequence, then make my insert, hence two network round trips. This makes for a big impact in concurrency and performance. In very scalable Internet-facing applications, it is very important to be able to squeeze every last drop of performance you can from the RDBMS, which SQL abstraction layers get in the way of.
In my example, the best of both worlds is to abstract an order business object and then fine-tune the corresponding SQL queries for each RDBMS, that way you can still have a common body of presentation code.
The fact ArsDigita has chosen as an implementation and business decision not to make this business object layer sufficiently modular does not mean the ACS architecture itself is flawed, as the product can be refactored. Of course, this poses challenges to the OpenACS team since they want to leverage as much as possible the aD work.
With aD's move towards Java buzzword-compliance, I'm not sure this is going to be sustainable in the long term anyway, so the whole point might become moot at some point where only the module specs and design will be common to ACS and OpenACS, with the actual Java vs. Tcl implementations radically different.
Conversely, there is no reason Zope applications cannot be fine-tuned to have hot spots written directly to a RDBMS using hand-tuned queries. It will still be difficult to have good decisional support from an object schema shoehorned into a relational database, but it is certainly possible using triggers on the ZODB storage tables.
2. Comparing the frameworks
I installed ACS 4.2 Beta (Tcl) last March to play around with the workflow module, and I am now tinkering with Zope. The way I see it, ACS is more scalable than Zope simply because of the quality of the underlying web server, whereas Zope would be more scalable in terms of building large complex applications (where the customized part is significantly larger than the standard module part) on top of the framework. This is an oversimplification, of course, but Zope might be a better candidate for Intranets while ACS would be better suited for consumer or large community web-sites.
Zope certainly has no monopoly on limited documentation - I tried long and hard to build my own modules on top of the ACS 3.4 workflow facility in spite of the limited documentation, and finally gave up and rolled my own in Python.