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

[Jim Fulton]

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:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org