[Zope-dev] Re: [Zope3-dev] Two visions

[Gary Poster]

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  
> Zope.  It
>      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
>      significant degree.

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  
configuration.

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.

More below.

>    - 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)
>      application server.

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  
component designs.

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  
more.

(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  
good thing.

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.

Gary