[Zope3-dev] Two visions

[Jeff Shell]

On 2/27/06, Jim Fulton <jim at zope.com> 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