+1 on Jim's suggestion #2.
However, if I am understanding things correctly, it doesn't really sound
like door #2 entails a huge deviation from from our current course of
bringing Zope 2 and Zope 3 together gradually. I don't really care what
the converged product is called, be it Zope 2.250 or Zope 3.99 or Zope 5.
My take is that Jim is not really proposing anything all that different
from what Martijn wants -- a gradual convergence of Zope 2 and 3. Rather,
it sounds like the biggest changes in Jim's proposal #2 entail:
1) a change in how we _talk_ about what we are doing, and
2) an explicit attempt to factor out some of the Zope 3 goodness into a
more generic, less-monolithic-app-server framework, Zed (or Z or
Am I right here, Jim?
I think that the idea of giving Zed its own, distinct identity is great.
Zope 3 is a _huge_ overhaul and it needs to be obvious to the world that
it is dramatically better than crufty old Zope 2. Zope 3 then becomes the
Zed application server; Zope 2 is getting Zed retrofits via Five, and the
two will eventually converge into Zope 5 (or Zope 2.27 or whatever).
A distinct Zed distribution could bring in developers who are just
interested in using the component architecture but not necessarily a big
app server stack. It would be cool to see Zed popping up in random python
products or perhaps even in TurboGears / Django internals. And more than
just cool -- the more people we can get using Zed, the more code we will
be able to mix in easily to Zope (2/3/5) applications.
Zope3-dev mailing list