+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? 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. Geoff _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com