Max M wrote:
Jim Fulton wrote:
2) In an alternate vision, Zope 2 evolves to Zope 5.
Zope 2 is complicated! It has too many layers of everything.
The reason for Zope 3 is to make it simpler for developers.
Therefore I believe that any succesfull strategy would require Zope 3 to
be usable completely without all the Zope 2 layers.
If Zope 3 becomes just another layer on top of Zope 2 -> CMF -> Plone it
will not reduce complexity, as any developer would still need to learn
the entire stack.
Wherever practical, Zope 2 technologies should be rewritten to Zope 3
technologies to remove layers from the stack.
I think these are good points.
Five runs the risk of being yet another layer on a stack like Plone, but
Five also gives the chance of us stripping off these layers and
replacing it with something cleaner, and at the same time Five is giving
an impulse to Zope 3 development as things slowly get ported to Zope 3
or written in a Zope 3 style.
The Five project has the right attitude to deal with such integration
issues. We have been quite successful: In Zope 2.9 it's possible to
build modern Zope 3-style apps, using formlib and sqlos and so on (we've
In this vision, the Zope 3 project should stay where it is and push
things forward. That doesn't mean Five should be ignored by Zope 3
developers, but it should be compartmentalized in people's minds. Zope 3
does innovation, Five does integration, and then the big codebases can
move forward using both.
Zope3-dev mailing list