On Feb 27, 2006, at 10:37 AM, Jim Fulton wrote:
2) In an alternate vision, Zope 2 evolves to Zope 5.
Of the two, this seems more believable. It also may be the best we
can do. However, I still don't like it. :-)
- Zope 5 will be the application server generally known as
will be backward compatible (to the same degree that Zope 2
releases are currently backward compatible with previous Zope 2
releases) with Zope 2.
This is reasonable, though I don't love it.
Zope 5 will similarly be backward
compatible with Zope 3 applications built on top of the current
Zope 3 application server.
This gets to the heart of my concern, I guess (see below).
Note that Zope 5 will leverage Zope 3 technologies to allow a
variety of configurations, including a Zope 2-like configuration
with implicit acquisition and through-the-web development, and a
Zope 3-like configuration that looks a lot like the current Zope
3 application server. Maybe, there will be a configuration that
allows Zope 2 and Zope 3 applications to be combined to a
You say that one of the advantages of this vision is that "There
wouldn't be confusion about 2 Zopes". I'm afraid that's wishful
thinking, if you want "Zope 5" to include a Zope 3-like web
If you are going to pursue a "Zope Five and the artist formerly known
as Zope 3" vision, in which Zope is a single clear product, then it
seems to me that Zope Five should be one or the other, and that's
what books should describe. A Zope 2 derivative a la Five makes
sense, given Zope's history and current users.
- Zope 3 will explode. :)
For many people, Zope 3 is first a collection of technologies
that can be assembled into a variety of different applications.
It is second a Zope 2-like application server. I think that
these folks aren't really interested in the (Zope 2-like)
There are some--Steve Alexander and Canonical, maybe?--who might not
care about anything beyond choosing among the bag of technologies.
But I assert with the right of speaking loudly (i.e., I have no way
to prove this) that there are many who appreciate the "bag of
components" design who still want to buy into some of the "Zope 3 as
web application server" story.
For instance, if you mean by "a Zope 2-like application server" "an
Object File System approach" then I certainly hope you are wrong.
Even though I don't care much about the Zope 3 ZMI, Zope 3
encapsulates some web app design decisions I would be loathe to
lose. I much prefer the Zope 3 approach to OFS, with __parent__
rather than acquisition wrappers, a dict interface rather than
objectValues and friends, and traversal adapters rather than
__bobo_traverse__ and friends. If acquisition and all the rest are
on the way to being replaced within Zope 2/5, then...yay? but then
how is it still "Zope 2 backward compatible"? They seem core to Zope
2 to me. And the Zope 3 versions of the decisions inform many Zope 3
Do you mean that the Zope 3 users don't need Zope 2 cataloging and
indexing? Surely not, and yet again moving Zope Five to the Zope 3
catalog seems pretty questionable as "Zope 2 backward compatible".
And I *much* prefer the zope.index/zope.app.keyref/zope.app.intid
combo in Zope 3.
Do you mean that Zope 3 users aren't looking for a better designed
web app than Zope 2, that looks less "long-in-the-tooth" (as I've
seen blogs call Zope 2), that has more industrial-strength
flexibility and hard-won design experience than the current crop of
competitors? I don't think so: I assert that developers of a certain
inclination are attracted to the cleanliness of Zope 3 as a web app,
and not as attracted to the cruft that accumulates in an older, very
successful project like Zope 2. Some of those are new Zope
developers, and some are prominent older Zope developers.
Do you mean that Zope 3 users don't want a robust, battle-hardened
web publisher like the Zope 2 publisher? I think many do.
So, I assert that many Zope 3 users, who are in it for the "bag of
components", *do* want a web application server. If I'm
misunderstanding you, then, as Stephan said, maybe you could explain
(Almost done, but still more below)
Zope 3 will continue as a project (or projects) for creating
and refining these technologies.
(It would probably make sense for this activity to to have some
name other than "Zope". On some level, the logical name would
be "Z" (pronounced "Zed" :). An argument against "Z" is that
it would be hard to google for, but Google handles such queries
quite well and I'd expect that we'd move to the top of Google Z
search results fairly quickly. However, I'll leave naming
decisions to experts. ;)
If this is the plan, then I guess I just think that "Zed" needs to
include an app server, and needs to keep on living independently.
"Zope Five" needs to be Zope 2, bumped up (rather inexplicably to the
outside world) to version 5. OK.
I'm excited about the prospects of a Zope Five that shares "Zed"s
publisher and gives it the workout and battle-hardening it needs.
I'm excited about the prospects of a Zope Five that encourages Zope
2/5 developers to think of themselves more as Python developers, and
ZODB component developers. But I'm not excited about losing the
changes and wins that a rethought-Zope 3 web application brought.
Zope 3 is not just a bag of nice technology: it is a conscious
rejection of some core Zope 2 decisions. I think the rejection was a
Finally, I'm also skeptical of a vision that claims "unity" when,
with the "Configure Zope 5 as Zope 3" approach, all it seems we will
have gained is unity of name, rather than true unity of vision.
On the other hand, maybe that's enough. I offer my observations with
humility, and true appreciation of what you and others, like Philipp,
are trying to do. As Andreas says, maybe this is the best we can
do. I wish I liked it more.
Zope3-dev mailing list