Geoff Davis wrote:
+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
ZomethingElse).
Am I right here, Jim?
Yup. Realizing that there are two distinc efforts (the app server
and the collection of technologies) and making that distinction clear.
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).
Ooops. OK I guess I was clear as mud. :) My idea for "Z", pronounced "zed"
or whatever the naming gods decide is that it was *not* an app server.
It is an un-app-server. :) A collection of technologies that are useful
by themselves, to support an app server and useful to build non-app-server
applications, web or otherwise.
I think that Z3 is better than Z2 in a lot of ways. I also think that
Z2 is more mature and complete. I really want us to combine those efforts.
I think we've achieved enough and learned enough with Zope 3 that we
can now bring that to bear and make Zope 2 better, refactoring the cruft
away and applying the lessons we've learned with Zope 3. (Note that Zope 3
is not crust free.) I don't really care what this thing ends up being called,
except that it *must* be called Zope.
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.
This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's
advice and release our technology in bite-sized chunks. I'm hopeful that the
packaging efforts underway will lead to more of that.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
