On Thu, 13 Jan 2000, Derek Simkowiak wrote:
discovered. However, I have the following "fears":
2) I will get trapped into the product
*But*: (there always is, huh?) The learning-curve of Zope appears to be S-shaped, and the steep part is *very* steep.
I'm a C programmer by profession, so I'm not worried about it. I'm more worried about investing two months into DTML and "Zope Object" designs and code only to find out that the server load is too high, or that I can't do something that I'd like to, and then have to restart the project with Apache, PHP, Perl/CGI, etc.
I would expect Zope to compare favorably with other dynamic content solutions. ZServer although written in python is quite fast. Medusa (on which ZServer is based) should be at least as fast as apache in serving dynamic pages, and Zope is certainly faster than straight cgi solutions. Zope is really composed of three pieces, an object database, the object publisher, and DTML. Zope is actually a framework based on these building blocks. Having used each component independantly I can say that they are all pretty fast and powerful. Now Zope adds overhead in terms of a security model, acquisition etc but you would have to design those for your case anyway. Remember also that DC is highly concerned about scalability issues and they already provide solutions like the ZEO, a distributed version of ZODB. In terms of component access I would think that Zope is the best solution on the market, as it is based on python, which is easily extended in C or C++ and has a very active community. If you want actual numbers I suggest you write a small application and serve it directly from ZServer (I can send you one if you want) and compare it with one written in Perl/CGI PHP. Pavlos