InfraStructure

RDBMS

Postgres with pl/pgsql stored procs.

Webserving/MiddleWare?

Zope

Pros

rapid development (for those who experienced with it)
python
flexibility

Cons

if content is primarily relational than much of zope's goodness is lost.
no support of bind variables for zsql methods
requires patching of zpublisher to add in soap support, such support may or not transparently expose all objects to soap calls.
requires careful design to avoid hotspots for non relational content.
lots of magic.
additionally, i have concerns about zope's throughput per node for a primarily relational site.

Aolserver + OpenAcs? + Python

Pros

scalable
proven in this context
great rdbms integration
lots of community functionality and infrastructure with the acs
integration with python via PyWX
possibly running with only select acs libraries.
robust internal scheduling system.
api for threads sharing data
easy to add in soap/xml-rpc support with python

Cons

the programming model which is fundamentally relational requires reading alot of documentation to learn the various apis.
not pure python
longer development cycle than with zope.

Webware

Pros

clean architecture no magic
fast and python
easy to extend

Cons

relatively new/unproven.
not much by way of plugin packages.

Thoughts

The Winner

I think i'm pretty set on using aolserver, as its fundamentally oriented towards doing database backed websites. I'm going to investigate use of PyWX? for some processing (esp pyxml instead of ns_xml's libxml interface). The biggest problem is social, lack of support from the python community and loss of potential developers, and the potential loss for avoiding duplicate work for a zope-repository. Further investigation of what acs tcl library functionality can be reused. if there is strong dissent in the python community than this option might not be viable...

Why not Zope

In an almost entirely relational site the use of Zope on technical merits seems rather moot.as for why not do it in a non-relational system, hmm.. the more i've worked with it from a relational perspective i can definitely perceive benefits from doing it in a zopish way. but the promise of pre built functionality offered by the acs that will integrate easily is compelling.

Why not Webware

Quite honestly i just don't know it well enough, nor have i seen it used in enough contexts to trust it.

Updates 10/3/01

I've got a working aolserver + PyWx?. the datamodel is coming together. i'm going to be using openfts.sf.net for site searching, although i'm wondering if it makes sense to use a different engine for indexing metadata for keyword searching. other candidates swish++ and lucene.

talked to author of pywx re support and continued development, things seem pretty solid.

talked to don baccus of ybos, release coordinator for openacs4. i'm still a little concerned about using the openacs-4 for the site, it would open up a lot of functionality but it would require alot more work in tcl and plpgsql, on the other hand it would offer tremendous boost in productivity and functionality. sigh... i've made the data model somewhat similar to the acs object model so it should port over fairly easy if this becomes a no brainer.

read up the aolserver c documentation since pywx comes with almost none, not as much functionality as exposed as i thought, still quite a bit, and the rest python can do.

i need to investigate whether or not i can use tls/tss storage for pywx, mainly for creating template contexts and the sql engine, else i'm stuck with doing most of the site in tcl, since i really would like some sort of templating and db abstraction.

Updates 10/5/01

I've decided to use the openacs for the site, the amount of time saved and the amount of extra functionality gain make it seem like a fairly straightforward decision, my only concern at the time was speed issues, but it seems likely that i can get 12hits/s out of it w/o clustering on db backed pages.

Updates 10/27/01

I've uploaded the data model to date (see CodeReleases?), which is basically non openacs functional. at this point all future work will involve openacs integration. To further elaborate on why use the openacs, basically membership, indexing, workflow, permissions, and prebuilt community modules.

Updates 11/15/01

Further Updates on infrastructure will be posted to the GideonArchitecture page.