Forum OpenACS Q&A: Response to Article on ACS x Zope

Re Ecommerce support. I'm glad to hear the ACS module is likely to be easy to configure and will try it out. Will also follow up the suggestion to checkout Zcommerce etc and ask any further questions about Zope ecommerce in the Zope community. Question resolved.

Re scalability. Question still open and seems appropriate to explore here. I'm not convinced by Don's view either that ACS owes its scalability to the efficiency of AOLserver and the database drivers, or that while Zope is untested in this area there is no reason to expect that anything intrinsic to its architecture is likely to run into problems at the high end.

It appears to me that a really major part of ACS is a solid underlying data model that reflects a lot of work put into thinking about *how* to integrate web servers with databases. In porting the syntax from Oracle to Postgresql and in adding modules to ACS this data model can to some extent be taken for granted, but I suspect its vital to scalability.

My reason for concern about Zope's scalability (as opposed to any claim that it won't) is strengthened by the very helpful description of Zope's complete storage independence given by Chris. This has many obvious advantages, but the trade off may well be scalability. If data has to be persistently stored on disk and read from disk instead of all being cached in RAM, the effective limits to scalability can often become the physical seek times of disk heads. The very flexibility of objects relating to other objects through links as required, can then translate into multiple disk seeks as you traverse a path from one to another. SQL partially shields the platform developer from DBA/sysadmin work optimizing disks and indexes, and an abstraction layer further shields add on developers. But this is only partial. The flexibility of an RDBMs application platform and its add ons is in fact limited by the data model. If it wasn't it couldn't scale.

So far OODBMs have proved their advantages in maintainability, adaptability, flexibility etc in applications where relatively small numbers of users are simultaneously accessing highly complex structured objects. Yet RDBMs have remained dominant, not just for "historical" reasons, in large scale On Line Transaction Processing. Large "community" web sites may turn out to have characteristics more like OLTP.

I suspect the future belongs to peer to peer distributed networking between clients where the user is participating in many different communities and needs powerful adaptable software on the client (or a local server shared among various clients but not related to any particular "community"). A distributed version of the Zope approach could be very applicable to that future, making it very different from the now "kludgy" current distributed networking of net news and email list communities, and superior to large scale community web sites.

But I don't see how simply declaring complete independence from storage can change the fact that with current hardware, large scale web applications cannot hold their persistent data in battery backed RAM and therefore ARE dependent on storage structures.