Okay, a few points.
Object-Oriented is great for a number of things, but you have to be careful about a few gotchas. For example, if you use an RDBMS, plopping objects on top of that is usually a nightmare, no matter how good your object-relational mapping is. I can go into extensive detail about this if anyone is truly interested, but I'll spare you for now :). Now, an OO model for certain levels of the code, like the modules, may not be a bad idea, but it's questionable that it's the only way to go. Defining a module callback interface with module registration will work just as well for our purposes here. All I'm saying is that we should think carefully about architectural changes that broad: we don't want to get stuck with a massive porting/rearchitecturing effort on our hands that not enough people want to support.
Another important point: making things modular, abstracted, and extensible, is perfectly possible in Tcl. I'm sure Python is a great language, but let's think here: how hard is it already to find
Tcl/SQL hackers? Do you want to add Python to the equation? I don't. I think it's great to have people explore different ways of using AOLserver, but let's not get into language wars for ACS purposes. Tcl, Python, C, Java, Perl, Lisp are all Turing-complete, you'll be able to do anything you want in any of these languages. Yes, you may love one language more than another, but we have big issues on our hands here (modularity, content abstraction, DB compatibility), and introducing another unnecessary piece to the equation is a suboptimal approach.
