Forum OpenACS Q&A: Response to Article on ACS x Zope
2) A significant volume of transactions that have a relatively high ratio of writes to reads. Any OODBMs is better at a high ratio of reads to writes and the ZODB is "aggressively optimized" for that situation. This makes Zope very good for combining "dynamic" (but read only) web pages with decentralized administration and maintenance of the site, including product catalogs unless they are volatile and large. The writes required for such ongoing administration and maintenance are relatively low volume and the transactional support provided by ZODB should be adequate, with much easier and more flexible customization through Zope. However I can't see it working for any significant volume of "shopping cart" and payment transactions, or even a reasonably volatile user base, let alone the individual page tracking and correlations that ACS ecommerce provides. These are fairly static applications so ease of development and customization is less important, but the high volume of actual writes is more important. Given that ACS has already done the main development and OpenACS has ported it to a viable open source RDBMS, there should be no need to duplicate those major efforts. As far as I can see the ZODB would still be navigating via pointers as an OODBMs and the fact that its "storage" happens to be within an RDBMs would not change the fact that each navigation would still require at least one full disk seek for every write. How would any benefit be obtained from RDBM indexing, clustering etc if the ZODB is just appending each object to a single RDBM table?
[RM]
I have been working with a client who has gone for ACS over Zope mainly because
of the lack of ecommerce on RDBMS in Zope. Yet it seems to me that Zope has so
much potential, and the Zope products which don't need RDBMS are so attractive,
that it would be an ideal platform to incorporate both.
[AL]
This sounds similar to my situation. I'm actually recommending use of OpenACS ecommerce module in parallel with separate development of other aspects of a site in Zope. Still not sure whether THAT will be the best or worst of both worlds 😉
Glad to find at least one other person caught between the two worlds who might be interested in figuring out how to minimize the pain in the bum that one gets from trying to ride two horses or sit astride a sharp fence!
Seems to me that OpenACS faces related problems just from needing to keep in sync with ACS while also needing a data abstraction layer, but not being particular interested in Zope as such.
The way I see it:
ACS has a body of expert knowledge of the problems of RDBMs based web sites but is not interested in any RDBMs platform except Oracle. It also adopted a sound architecture getting away from CGI by using the web server as the RDBMS client. It is already running into the limitations of non-OO large scale development but has no real understanding of OO design. I have the impression most RDBM people think the OO stuff is just an overcomplication for web related stuff that can be done more easily without it. (The fact that they actually did build ACS without it and Zope has nothing comparable in important areas such as ecommerce confirms that view, but says nothing about what happens when the much larger and more complex systems made possible by what they have already achieved just keep on growing and becoming less and less maintainable).
OpenACS understands the importance of that body of expert knowledge and needs to stay in sync with ACS to continue benefiting from and contributing to it, but also needs at least a data abstraction layer while not having much interest in anything more OO than that. OpenACS is likely to have the greatest appreciation of the need for a solid data abstraction layer.
Zope has a similar architecture to ACS as regards getting away from CGI and using the web server as the database client. It has a thorough understanding of OO design but only a minority that would appreciate the importance of the body of expertize ACS has made available on RDBMs based web sites. (In particular the very specific issues for ecommerce which ACS achieved an understanding of through hard experience are not yet understood). I have the impression most Zopers think that just because the OO stuff completely abstracts the database from the viewpoint of application developers and content managers, the body of expertize ACS has provided is simply irrelevant. (In particular ecommerce looks like just another app). Their concept of a data abstraction layer seems to be limited to a data abstraction layer for talking to Zope.
I'm hoping that there might be some interest among OpenACS people in working out how to decrease the coupling between the RDBMs based modules of ACS by a separate data abstraction layer that would ALSO make it easier to use those modules with Zope (or any other application platform) AS WELL AS their primary concern of making it easier to use them with Postgresql and other RDBMs as well as Oracle.
If that is possible, it strikes me as a better solution than simply migrating the modules to Zope or any other particular platform. As "stand alone" modules they could be kept in sync with their original development as part of ACS instead of forking off and duplicating effort.
Something like an XML-RPC interface to ecommerce application domain objects stored in the RDBMS?
[RM]
I have done some work with Zope and RDBMS and I've found it powerful and
effective.
Perhaps after I have worked with the ACS ecommerce product I may be able to
comment more about implementing it in Zope.
[AL]
Sounds like you could be ideally placed to take the initiative in getting people interested in making it "stand alone" so that it could keep in sync with ACS as well as being available to Zope. Any interest in that cf "forking"?
I am cross posting this to the Zcommerce list:
http://lists.codeit.com/mailman/listinfo/zcommerce
as well as to the OpenACS bboard below.
Will also be posting correspondence with Paul Everitt, ChrisMcDonough and Kevin Dangoor to Zcommerce for discussion there as promised.
Will be tracking any discussion in either place but without any further cross-posting, so anyone else interested in both would need to be subscribed to the list above and also use the "notify" facility on the bboard below.
[robot]-----------------
To post a response, come back to the bulletin board at
