This week, Stephen Ibaraki, I.S.P., has an
exclusive interview with Stephan Richter.
Stephan has been involved with Zope since
1999 including Zope community activities such as documentation, and organizing
the first EuroZope conference, plus working with Zope solution providers,
developing add-on products, publishing books on Zope and taking a lead on Zope
Stephan is a Ph.D. student in Physics at Tufts
Q: Stephan, as a leader and well-known
contributor within the Zope community, we are fortunate to have you with us.
Thank you for sharing your expertise with our audience!
A: Thank you very much for the opportunity
to spread the word about Zope, specifically Zope 3.
Q: Before we get into your Zope activities,
let us explore your passion for physics. Describe your thoughts on numerical
analysis of quantum lattice systems and quantum computing? Where do you see it
all going in the future: say 5, 10, and 20 years?
A:� This is a really exciting time for quantum computing, both theoretically
and experimentally. As you may know, it has been proved that we can develop
more efficient algorithms using quantum computers. To implement a quantum
computer we need many thousand entangled quantum states (known as qbits). The
current world record is to have 8 entangled qbits. So you can imagine that
there is a lot of work to be done. Also, we currently do not have any cheap way
of producing qbit devices. Most experiments are done near absolute zero
temperature, a setup not suitable for an average person. Another important
experimental challenge is to implement the CNOT (controlled NOT) gate, which
has been proved to be a universal gate for quantum computers.
On the theoretical side physicists and
mathematicians try to develop new algorithms, such as quantum lattice systems
using quantum logic. However, theorists are also dealing with error correction,
since not all algorithms in quantum computing have to give you an answer with
Q: Can you comment on your future with
teaching and research?
A: Honestly, I am not the research guy.
While doing my Ph.D. I want to do a really great project and enjoy it. But I
currently have no ambitions to do research later. To me the Ph.D. is simply a
necessary milestone to do what I truly love: to teach. Tufts already gives me
many opportunities to develop my teaching skills. Besides teaching recitations
and labs, I have taught the introductory Physics course in Mechanics during the
summer and the classical computing part of a Quantum Computation and
Measurement course my adviser gave. I have also been vocal about improving the
laboratory components of the introductory courses and hope that I will be part
of the group restructuring them during the summer.
After my Ph.D. I hope that I will find a
university that will hire me for my scientific teaching skills. I want to
explore more methods of teaching. I am particularly interested in the
non-conventional use of technology and �toys�, such Lego(tm) blocks to
demonstrate principles. Maybe this will become my future research area; who
Q: Share with us your experiences with
Jason Orendorff, who taught you Python.
A: Wow, you dug deep! I knew how to program
Pascal (including the CGI extensions) and a little assembly by the time I
entered college. It was all self taught, but good enough for some
high-school-level science competitions. Jason and I met the first time in the
computer labs of Christian Brothers University. He was a senior working in the
system administration group and I was a freshmen. I proudly showed (well,
bragged) some code to friend of mine, when Jason came to the computer, looked
over my shoulder and said: �This code sucks!� Well, you would think that we
were both off to bad start, but I challenged his remark and we developed a
Later that year, Jason taught some Python
classes to interested students, which I attended. However, Python was so
different to me at this point that I had a hard time and I did not know much
about the formal terminology in computer science. At the end of the first
semester, I joined the system administration group, where I was given tasks to
write some Web applications. During this time Jason coached me a lot and I was
soon proficient enough in Python and Web application development to help
computer science seniors with their final projects.
Over the years Jason not only taught me
Python, but also object-oriented programming (with which I had great difficulty
at the beginning), Java, Jython and much more. He also got me my first
Web-application programming job at iXL(tm), one of those Internet Bubble
companies. It was at iXL, when I heard about Zope. Thanks to Jason (and
some other great people) I was able to finish college without taking out any
loans or financially stressing my parents.
Q: How would you describe Zope and its
evolution to various audiences?
A: (a) HTML Developer/Hobbyist - Zope was
really never aimed at this target audience. However, as more products were
developed, people could install Zope and the products they wanted without much
hassle and have blogs, discussion boards, and much more in no time. With the
development of high-level CMS systems, such as Plone, CPS, Silva and icoya, the
entry level became even lower allowing this group of people to use Zope to its
In Zope 3, as new as it is, we have not
addressed or targeted this crowd at all yet. However, I am hopeful that we will
see high-level CMSs being developed in the next years that will make Zope 3 as
accessible as its predecessor.
(b) Web Scripter - The scripter is a person
that knows how to develop dynamic Web applications using scripting languages,
such as PHP, ColdFusion, ASP, JSP and so on. It was the original and is the
main target audience for Zope 2. Zope always tries to provide great development
facilities to the scripter, such as Zope Page Templates, Python Scripts and SQL
Methods. Using these three concepts alone, the scripter can build powerful
SQL-based Web applications. Once the scripter becomes more familiar with Zope,
other through-the-Web development features are available to him/her, such as
ZClasses, which allow object development by clicking some buttons. All this
functionality has been even further simplified in CMSs such as Plone.
In Zope 3 we have not addressed this
audience at all, since we first wanted to provide a good experience to the
audience below. However, there are already several goodies in the repository
that will make the scripters heart beat faster. Such features include
persistent Python modules, persistent schema-based content types, and SQL
expressions for Zope Page Templates (more generally, TALES).
(c) Python Developer - While not one of the
target audiences, it felt always natural to develop and extend Zope through
Python code. A huge amount of Python products have been developed for Zope 2
this way. A lot of documentation has been developed and newcomers can look at
the existing code for help. The main critique Zope 2 gets from Python
developers is that its APIs are big and that it is unnecessarily hard to
incorporate other 3rd party Python packages.�
Zope 3 is all about the Python developer.
Its goal was to make it as easy as possible to develop new Python-based
extensions and incorporate 3rd party Python packages. And I think we have
succeeded. Thanks to the component architecture, any component in Zope 3 can be
easily removed and replaced by a custom implementation, allowing one to
customize/extend Zope 3 as little or as much as one desires.
Q: What is the situation with Zope
A: This is a really difficult question.
Before giving an answer, let me make an analogy. Zope could be compared to
Linux, where Zope itself is really just the kernel. The add-on products could
be compared to tools based on the kernel. The high-level CMSs are almost like
distributions that contain the kernel plus many add-on products. Then I, as a
Zope 3 core developer, am a Linux kernel hacker that works on the next generation
Thus, it is very difficult to see the whole
picture. The Zope community has grown beyond the sight of a single individual
so that my answer will be based on the tidbits of information I have. I am
personally most familiar with the situation in the US and Europe.
Since the US is far more conservative in
comparison to Europe, the acceptance of Zope grows slowly, but steadily.
Companies, such as Zope Corporation, show that one can compete successfully
against the giants, such as IBM Websphere, BEA WebLogic and Vignette. Also, the
deployment of high volume sites, like CBS New York and boston.com, give Zope
more and more credibility. Plone, one of the CMSs built atop Zope, also
increases the visibility of Zope in the corporate environment due to the
numerous Plone-based sites and its mentioning in the media. Another indicator
of Zope's success is the fact that several Zope-originated technologies, such
as the TAL/TALES standard and the Plone CSS style sheet, have been ported and
implemented by many other software projects.
In Europe, Zope is much more widely
accepted and the biggest competitor is PHP.� The French and German government, for example, have both deployed
numerous Zope Web applications. Plone, CPS, Silva and icoya took really off and
many of the systems integrate well with other software commonly used in Europe,
such as SAP. Community life is also much healthier. There are constantly
meetings and small conferences all over Europe and Zope solution providers
often share projects.
Q: You believe in the �real� application
development capability of Zope. Can you comment on this? List ten ways it is
superior to other systems or frameworks!
A: I had to dig on Google to find the
context I said this in (which is different than what I thought). In the
original context I was referring to the fact that I can develop Web sites using
Zope very much the same way I would like a GUI widget-based application. I can
separate presentation from logic from data and do so in an object-oriented
fashion. If you develop Web applications only using scripting languages, such
as PHP or ASP, it is very hard to separate the concerns let alone develop
object-oriented code. The end result is that scripted Web pages are
Here is the context I thought of when I
read this question. Zope is often considered a Web-only application framework
or even worse a Web-CMS-framework. I very much dislike this categorization,
since it unnecessarily restricts Zope's capabilities. Zope, in my opinion, is a
network-application framework which can be used to develop standalone
applications or simply to glue many different services together. With Zope 3 we
hope to have created an application framework that is even well-suited for
desktop application development.
I don't think it is necessary to list ten
ways in which Zope is superior. They would eventually all boil down to the
(1) Zope is written in Python! The best
decision the original creators of Zope ever did was to choose Python as their
programming language of choice. Python is ideal for rapid application
development, since one does not have to worry about static typing or compiling
while still having all the benefits of a powerful, object-oriented, modern
programming language that comes with �batteries included�.
(2) Object Publishing - In Zope the path of
a URL is interpreted as a path to an object. This process is known as traversal
and the rules on how the path is traversed are completely pluggable. Once the
object is found, a method is called on the object by a component known as the
Object Request Broker (ORB). The ORB knows what method to call - by inspecting
the request - and with which arguments to call it. This allows the programmer
to think about the application from a functionality point of view instead of
the perspective of HTML pages (presentation).
(3) Zope Object Database (ZODB) - Zope
comes with its own object database that is able to store any Python object. It
has many advanced features, such as transaction support. Over the years the
ZODB has been proved to be very scalable, especially in combination with load
distributing software like the Zope Enterprise Objects (ZEO), which allows it
to spread the ZODB over several servers.
(4) Free Software - At least in comparison
to its commercial counter-parts, Zope being published under the Zope Public
License 2.1 - a certified Free Software license - is a real advantage. People
do not have to worry about licensing issues, have access to the source code and
can reuse code for other projects. Several packages originally developed for
Zope are now used by many other Python applications.
Q: Can you provide some good case studies
of Zope and illustrate how it is being used?
A: I have not worked on any end-user
applications in the last three years, so it is hard for me to come up with
particular projects in which Zope was utilized. However, there are several very
popular products that run very prominent sites.
Once Zope reached some maturity, the
Content Management Framework (CMF) was developed which serves as the foundation
for many of the Content Management Systems developed with Zope. As mentioned
before, the most prominent one is Plone (www.plone.org), which was used for
some NASA and Lufthansa Web sites. CPS (www.cps-project.org) has been developed
by Nuxeo, which has implemented many government sites. icoya (www.icoya.com),
developed by struktur, has been deployed on several international sites. One
CMS I did some work for is Silva (www.infrae.com/products/silva) by Infrae,
which was originally developed to be an XML-based system to manage the
university catalog of Erasmus University in Rotterdam. There I implemented a
tool that could convert Silva XML documents to publishable MS Word documents.
This functionality has since been further developed to also allow to convert
Word documents to Silva XML files.
But also Zope 3 has some success stories to
report. Many Mark Shuttleworth's projects, like the SchoolTool (www.schooltool.org), use Zope 3 as the framework of choice. SchoolTool is
meant to be a free school management software. The first component, SchoolBell, a calendaring application will be released in March 2005. Another
application sponsored by Mark is LaunchPad, which will be a package management
software for the new Ubuntu Linux distribution.
Q: What are the current flaws in Zope and
how can they be addressed currently and resolved in the future?
A: As with all other successful software,
Zope 2 shows signs of design flaws. Here are some of them:
(1) Multiple Inheritance - Python, unlike
many other object-oriented languages, allows for multiple inheritance, which is
often seen as one of Python's killer features and is thus heavily used in Zope
2. However, as Zope 2 became more popular and more functionality was added,
Zope 2's APIs became bloated to a point where it is very hard to implement any
object from scratch. You could say that we discovered with Zope 2 the practical
limits of multiple inheritance.
(2) Internationalization - Zope was
originally developed in the US and internationalization was not on the minds of
the developers. As Zope became more popular, it quickly spread to Europe and
special character had to be available. The problem was patched by using
encodings, but it was too late to make the Zope core unicode-aware.
(3) Implicit Acquisition - Zope was one of
the first frameworks to implement acquisition, which is basically inheritance
of object instances. For example, if attribute x is not found on the current
instance, it knows how to look up this attribute in the parent object. This
process happened automatically in every object that inherited a certain class.
Unfortunately, this feature caused some unwanted side effects, which were very
hard to debug.
(4) Documentation - While there are many
books available for Zope these days, people still complain about the lack of
documentation. I personally believe it is simply the lack of comprehensive API
and independent package documentation that still bothers people. Unfortunately,
due to the reasons in (1) it is very hard to develop this level of
The good news is that all these issues have
been well-addressed in Zope 3! In fact the API bloating problem was the main
motivation to start the development of Zope 3. The problem with multiple
inheritance is that it creates a tightly-coupled relationship between the
various object layers that cannot be decoupled. For Zope 3 we developed the
Component Architecture, which is based on objects having very small APIs, which
communicate via very well defined interfaces. Any component can be easily
replaced by another custom implementation as long as it properly implements the
Zope 3 was also implemented using only
unicode in the core. In fact, the first public developer meeting (sprint) was
aimed at this issue. Acquisition, being a very useful concept, has not been