The Zope Application Server Revisited - page 6
Many thanks for your piece on Zope in LinuxPlanet. It's always nice to see Zope get recognition as a member of the appserver marketplace. You raised many points with your analysis that Digital Creations and the Zope community at large has been pondering for some time. I'd like to discuss some of these below.
First, it's true that getting Zope integrated with Apache is pretty hard. We have thrown a lot of energy over the years towards improving this situation, but in the end, Apache is hard to integrate with. This lament is repeated in the FastCGI, Midgard, and Enhydra communities. We provide a pre-compiled, pre-configured "Zap" (Zope Apache) that helps this situation by demonstrating how it can be done. Since you didn't find this, it indicates that we need to provide more information.
Lesson #1: Create a "Reviewer's Guide" that quickly lists the resources needed.
At the same time, our move to FastCGI and particularly adding cookie-based authentication will ease the burden of plugging into Apache.
Next, you mention that Zope should support RADIUS. There is, in fact, a user-contributed "user folder" that hooks into RADIUS for authentication information. Editor: The review has been edited to reflect this fact.
Lesson #2: Provide links to prominent third-party packages in the Reviewer's Guide.
You say " [o]nce you get past Zope's insistence on using different terms to describe some widely used user-management strategies..." This touches on a theme you discuss that Zope has a jargon challenge. I agree. Writing the Zope O'Reilly book has forced us to confront and begin addressing this. People should be able to leverage concepts they have already mastered when approaching Zope.
Lesson #3: Being different can be good, being unnecessarily different can be fatal.
Concerning the "studio", this has been an area of major, major concern for us. We don't want to lose the "Internet architecture" of a web-based development environment, but we absolutely must improve the productivity of using Zope. Which is why we started the Zope Mozilla initiative. Unfortunately the press release went out the day after your article went up! Editor: Sadly enough, this is true. You can read more about the Zope/Mozilla agreement here.
Our goal is to seriously narrow the productivity gap with traditional studios while retaining an Internet architecture.
Concerning COM, CORBA, and EJB integration, you certainly represent a valid, traditional view of the marketplace. In this regard, though, Zope is similar to Linux, which bucked a trend that had NT taking over the world by now. Certainly the Java bandwagon is pretty loaded, but there is still a lot of non-Java sentiment out there. Chances are that we will provide a strong level of COM/CORBA/EJB integration, but ultimately we view the use of Python as a competitive advantage and a differentiator. We are focusing first on Internet-centric interoperability protocols, such as XML-RPC, SOAP, and WebDAV.
Concerning Zope performance, it currently falls under the "neither fast nor slow" banner. Zope won't saturate a gigabit ethernet, that's for sure! :^) However, Zope provides pretty high performance (10-80 hits/second) that covers a broad swath of Web site requirements and is very competitive with commercial content management systems.
I will take issue with a dichotomy you present on the last page. After convincing the readers that COM/CORBA/EJB is a must, you then assert that "...many of the folks working on a day-to-day basis with application servers aren't programmers and really don't want to learn Python programming..." Seriously, COM and Java are incredibly more complicated than Python. Someone that finds Python too hard to learn will surely not scale the COM or Java learning curve, in my opinion.
--Paul Everett, Digital Creations