On 2/27/06, Jim Fulton <[EMAIL PROTECTED]> wrote: > I'd like to get feedback on two possible visions for the future of > Zope 2 and Zope 3. > > 1) Our current vision (AFAIK) is that Zope 3 will eventually > replace Zope 2 > > - There will be lots of overlap between the Zope 2 and Zope 3 > lifetimes. (Zope 2 might be supported more or less > forever.) > > - Eventually, the gap between Zope 2 and will become very small. > requiring a small leap. > > In this vision, Zope 3 would have to become a lot more like > Zope 2, or we would lose features.
Most people would probably agree that we could stand to use features. The warring factions break out over which features to lose. I never thought about this as the potential destination for the "Zope 3 replaces Zope 2" vision, but it seems pretty obvious now. I don't think this is a tenable destination. At the least, it's not one that I'd stay on board for. Our own experiences at Bottlerocket have shown that many of our Zope 2 apps have a limited lifetime in terms of our own ability to support them. Whether our first crop of Zope 3 applications turns out better is yet to be seen. But we've effectively (perhaps not officially) made the decision that any of our software with a real future will be rewritten anyways. A slow migration through Five does not work - *for us*. I may have been holding on to this view a bit selfishly. We still use Zope 2 and have done a variety of different things with it. But with Zope 3, we feel a lot more in control. When starting a brand new Zope 2 application, we tended to ask each other a lot of questions like - "is this a small thing? can we just do it through the web?" "what about ZODB, should we stick everything in an RDBMS?" (the answer to that led to a couple of further development options built on tools and frameworks built in house). We still have questions similar to this when starting a Zope 3 based application, but there are a lot less back and forth disucssions around "well, if it grows, we're going to have to ..." "yeah, but we don't need that right now, let's just use ...", basically worrying about the gap between easy and direct script/template based development against moving it to product based development, versus how much harder many aspects of product based development felt for simple tasks. Not that Zope 3 is perfect in this regard. But it is a lot better. It could be better still. Which I believe is the point of #2: > 2) In an alternate vision, Zope 2 evolves to Zope 5. > > - Zope 5 will be the application server generally known as Zope. It > will be backward compatible (to the same degree that Zope 2 > releases are currently backward compatible with previous Zope 2 > releases) with Zope 2. Zope 5 will similarly be backward > compatible with Zope 3 applications built on top of the current > Zope 3 application server. > > Note that Zope 5 will leverage Zope 3 technologies to allow a > variety of configurations, including a Zope 2-like configuration > with implicit acquisition and through-the-web development, and a > Zope 3-like configuration that looks a lot like the current Zope > 3 application server. Maybe, there will be a configuration that > allows Zope 2 and Zope 3 applications to be combined to a > significant degree. Sounds scary. But then again, I find CMF and Plone scary :). No offense against those products, but they just do far more than we need to do. > - Zope 3 will explode. :) > > For many people, Zope 3 is first a collection of technologies > that can be assembled into a variety of different applications. > It is second a Zope 2-like application server. I think that > these folks aren't really interested in the (Zope 2-like) > application server. If one result of what's being discussed is that "Zope the Application Server" gains definition, I'll be happy. The line between "Zope 3 as library" and "Zope 3 as Application Server" feels too muddy for me today. It still *feels* like you either get all-of-zope, or you have a fair amount of work to do to get just-some-parts-of-it (he says, after losing a saturday afternoon understanding how a full Zope + ZODB instance starts up and gets all wired together, and how to use zope.publisher as a basis for anything else). I still don't fully understand what the application server side of Zope 3 really is, personally. But I would love 'Zope 3 as Library'. > Zope 3 will continue as a project (or projects) for creating > and refining these technologies. > > (It would probably make sense for this activity to to have some > name other than "Zope". On some level, the logical name would > be "Z" (pronounced "Zed" :). An argument against "Z" is that > it would be hard to google for, but Google handles such queries > quite well and I'd expect that we'd move to the top of Google Z > search results fairly quickly. However, I'll leave naming > decisions to experts. ;) Perhaps it's not the greatest name, but I've become enamored with *lib names like 'formlib'. 'zopelib' Hmmm. Not the prettiest thing. But it does say "Zope Library". If that becomes the *core* of the mythical Zope 5, awesome. I still like having a web server with Zope 3. > Advantages of this vision: > > - Zope 2 users don't need to leave Zope 2. yay > - Zope 3 doesn't have to reproduce all Zope 2 features. yay > - There wouldn't be confusion about 2 Zopes. > > It is important that Zope 5 be backward compatible with both Zope 2 > and Zope 3, although not necessarily in the same > configuration. Many people are building Zope 3 applications today > and they should not be penalized. > > Thoughts? Would it be a significant retread or loss of traction to do this now? I wouldn't want to be stuck with Zope 3.2 for another four years. On the other hand, if this gets the zope.bobo project moving forward, and re-addresses packaging/setup, I'd be all for it. Regarding packaging/setup, I'd like to answer "how do I install just part of Zope?"... Or I guess, really, I'd like to see something that (I guess?) works with paste.deploy, or an enhancement/replacement of the current instance home builder. One that would provide options like: * Create skeleton zope.publisher application. Provide your own storage. Best for completely custom or small applications using other available options for templates, etc. * Create skeleton zope.publisher + zodb application. Provide your own root and skin. Develop rapidly and store Python objects naturally without a translation layer. * Create full Zope 3 application server instance. Customize skins, packages, etc, by modifying configuration. Work with other Zope 3 application server packages easily! Maybe with options regarding the server as well. (twisted, zope.server, 'I have a WSGI server already'). But this way, all of Zope could still be in a single download (no having to pick through a hundred different "editions" ala Microsoft), but provide entry points for web application developers and situations that don't need the full thing. I see a lot of simplicity combined with a fair amount of power in some other offerings, from Ruby On Rails to TurboGears to Seaside. But I think that many of those (perhaps with the exception of Seaside) have a mediocre or magical core architecture that could grow up to suffer problems similar to those that affect Zope 2, problems that the component architecture is meant to solve. Those are my own selfish desires anyways. I still believe that if we can build and deliver a solidly defined core, then we (or others) can do anything on top of it - a full on replacement for ZClasses, continuations based development with through the web shadowing of file system code for custom inline tweaking, continuations based programming where a page fades away as a concept and it's all just live objects on a screen with a natural flow for development of state intensive apps, something without any of that for development of state-carefree content delivery apps with nice URLs and aggressive caching, and so on. :) So again, if this would help us define that core *and make it usable in a variety of configurations*, then again I say 'yay'. -- Jeff Shell _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
