|
 |
Turbo Screen Sharing
Adobe Acrobat Connect Professional offers users the ability to have a more productive and engaging web conferencing experience while providing the IT department with a program that efficiently utilizes bandwidth and minimally impacts the infrastructure. Learn More!
»
Informal Learning: Extending the Impact of Enterprise Ideas and Information
Forward-thinking organizations are turning to enterprise learning in their quest to be better informed, better skilled, better supported at the point of need, and more competitive in their respective marketplaces. Learn More! »
Rapid E-Learning: Maturing Technology Brings Balance and Possibilities
Rapid e-learning addresses both time and cost issues by using technology tools to shift the dynamics of e-learning development. Learn why more skilled learning professionals use these tools and how you can get a solution to keep pace with your business demands. »
Delivering on the Promise of ELearning
This white paper defines the framework to launch e-learning as a set of teaching, training, and learning practices not bound by a specific technology platform or learning management system. It offers practical suggestions for creating digital learning experiences that engage learners by building interest and motivation and providing opportunities for active participation. »
|
 | |
The Zope Application Server Revisited
Digital Creations Responds

Kevin Reichard
Friday, January 7, 2000 08:31:26 AM
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
« Back: Introducing Zope