Some Thoughts

Hi!

I've just finished reading the thread and would like to share my thoughts:

I think the number one problem to address is that programmer resources
are scarce. So in an ideal world we would like to switch to Zope 3 very
soon to make sure people don't have to code for a system that will,
eventually, be abandoned by its crew (Zope 2), and later have to port
things.

If everybody switched now, we would have an incredibly large work force
that should be able to migrate most of the Zope 2 features quickly and
also add a lot of cool new stuff. The sooner Zope 3 would be finished,
the smaller the migration issues would be. There would be only one
product to publicly market and no efforts lost in porting back and forth.

So much for the ideal world.

The reality is that even if a lot of people joined Zope 3 development
now the process would still take a lot of time:

- The core APIs are still in some flux, which is not bad in general, but
rather inconvenient for developing against them.

- The training capacities of the core team that are needed to integrate
the new developers are limited. Sprints do a very good job for this. But
still there a some limits.

- A lot of people need software NOW and can not take risks, so they will
not join the Zope 3 workforce before the first stable release.


So what should we do:

First of all, as Steve pointed out, there is an ideal group of Zope 3
potential users: People who need something that Zope 2 doesn't provide
(yet) and have a time frame of 6 months and more for the project.

These people have to be won for the project. They have to feel
comfortable that they won't invest work into a black hole. Their
customers will, even now, have to be persuaded that going with the
cutting edge is a good thing this time.

I am one of those. 80% of what we did in the KONTENTOR CMS is working
around issues with Zope2's limitations. And as I am planning to do
another iteration anyway, I could go with Zope 3 if I felt absolutely
comfortable with it.

So how could I feel more comfortable?

Limiting risks: Steve posted some helpful hints on how to develop in a
compatible way some days ago. Maybe we could build on that. The basic
concept was that you should:

    - write the core logic in Python

    - write a wrapper to make the stuff work as a service (or whatever is
      appropriate) in Zope 3

    - write a wrapper around that wrapper to make it run as a Zope 2
      object, inheriting from SimpleItem and such

I think people could benefit a lot from this. In some cases it might
even be possible to skip the second step for a while and directly wrap
around the Pythonic core.

The main issues will be with the front-end code I guess. We will need
some of the concepts we have in Zope 3 to be available on Zope 2 very soon.

I is my guess that everything that heavily depends on implicit
acquisition will be extremely hard to port to Zope 3.

Making ZPT work the same way in Zope 2 and Zope 3 will be the single
most important step. The other will be introducing services for all the
things that currently are done using MailHosts, Database Adapters, etc.,
and also introducing site managers (right term?) into Zope 2.

One example from KONTENTOR: We wanted to be really flexible with being
able to override objects somewhere on the site. E.g. you might want to
use a different breadcrumbs or navigation box implementation on a subree
of the site. With Zope 2 this is trivial as long as all the code is in
the (direct) acquisition path and just called by name. But you will end
up with a mess of methods and ZPT/DTML snippets lying around in your
content space, and eventually run out of unique names.

So we are currently using getMethod() and getChromeObject() methods all
over the site (from DTML and ZPT, as well as from Python code). These
methods can implement very advanced lookup strategies, taking the chrome
settings and the position in the aquisition tree into account. When we
change the place the actual chrome files are stored or move methods from
the ZODB to the file system, only the lookup methods are changed. All
this is, by accident, very Zope3ish (adapters come to my mind), so
moving to Zope 3 as a platform would help us replace a lot of our extra
code by standard Zope features ...


What's my bottom line: Concentrating on actual migration of OLD Zope 2
code will not help Zope 3 development, but block it. Concentrating on
making it easy to develop in a Zope 3 style NOW (forward compatibility
like with Apple's OS 9 => X strategy) will help speeding up Zope 3
development and not waste resources.

I think that there is no big need for porting stuff from Zope 2 to Zope
3 in general. If something works fine on Zope 2, don't touch it. As I
have pointed out on the Zoep3-dev list some days ago, Zope 3 (non-x)
should probably be shipped with a Zope 2 (optional) engine that
integrates with the ZODB and ZServer and is accessible from a unified
ZMI, but other than that is not interoperable with the rest of the
system. That should be enough for most "legacy" code.

The stuff that needs to be ported (or better: reimplemented) in Zope 3
is extra functionality that Zope 3 doesn't have yet. But to be honest,
my guess is that from the 1000 or so products on Zope.org only a few
need to have feature equivalents in Zope 3. Most of those are database
adapters and the like, which are easy to port because they are based on
a Python core that just has to be rewrapped differently.

The need people will have is mostly developing NEW stuff or new releases
of old stuff for Zope 3.

If programmers feel that Zope 3 will save them more time than Zope 2
does, they will switch.


Finally, some general statements:

With regard to Java: I personally have NO interest in a Java port. I'd
like to see parts of Zope ported to native C/C++ for speed, but I don't
need yet another language involved. I think that Zope has absolutely no
chance as a new player in the Java world. Our strategy always has been
to either catch people before they go Java or after they have been
disappointed by Java. Yes, that means that we are not completely
buzzword-compatible. And yes that means that Zope will remain in a
niche. But it's a comfortable niche, and buzzwords are just fads that go
away. Good software survives.

ACS from ArsDigita was a perfect example of "GO JAVA => GO BANKRUPT"*.

We don't have to reimplement that strategy.

The other buzzword is XML/Web Services. We should rather go that way
where appropriate. If you are compatibly with Java (and .NET)
applications' interfaces you don't need to use their implementing
programming language ...

The last one: All I expect from Zope is RAPID DEVELOPMENT of powerful
(mostly web-centric) software. So everything that makes development
easier is a GOOD THING (TM) for me, everything that makes things more
complex is bad.


Cheers

Joachim



* This is not a general statement about Java, just about adopting Java
with only the buzzword compatibility in mind ...


-- 

iuveno AG

Joachim Werner

_________________

Wittelsbacherstr. 23b
90475 Nürnberg

[email protected]
www.iuveno.de

Tel.: +49 (0) 911/ 9 88 39 84