[Zope3-dev] Re: Zope 3 Roadmap thoughts

[Joachim Werner]

Some comments on the Zope 2/Zope 3 compatibility thing:

I think it is extremely important to have a clearly defined migration 
path from Zope 2 to Zope 3.

On the other hand I do NOT think that this must mean that Zope 3 as an 
architecture is actually compatible with Zope 2. Zope 3 is very 
different, and it has to. Otherwise we could just go on using and 
extending Zope 2 forever. There are new concepts that don't fit too well 
with Zope 2, and making Zope 3 completely compatible would break some of 
the benefits of the component architecture.

I'd like to see the following:

- For people who are currently running Zope 2 applications, there should 
be an up-to-date Zope 2 engine. If possible, this engine should use the 
Zope 3 version of ZODB (and provide a migration tool for that) and the 
Zope 3 http server component.

- The new ZMI (whatever name it will be given) should integrate with 
Zope 2 and Zope 3 applications, so managing both from one interface is 
possible.

- An easy migration path for Zope 2 data structures should be provided. 
It seems to me that this will have to be limited to very well-known data 
objects like the CMF objects, Images, and File objects.

- Resources like database connection information, user folders, etc. 
should offer migration tools so that one can export the configuration 
data, user credentials, etc. to a Zope 3 application.

IMHO for code objects (DTML etc.), the different concept of explicit 
rather than implicit acquisition and some other architectural 
differences will not make an easy "automatic" migration possible. It 
would be cool, but that sounds a bit like AI magic ...

For the rest of the code and applications migration will not be 
"automatic". In fact the applications will have to be completely 
rewritten. But from what I expect Zope 3 to offer this will be a good 
thing. If you don't want to use the new features you can keep using the 
Zope 2 engine. If you want to use them, you have to get into Zope 3 and 
rewrite some code. For what we are doing at iuveno I expect Zope 3 code 
to reduce my own code's complexity quite a bit. So I don't fear 
migration. I am looking forward to getting rid of the workarounds needed 
in Zope 2.

I completely agree with Jim that finishing Zope 3X soon is more 
important than considering compatibility issues now. To know about the 
upcoming migration issues we will first have to know the migration 
target, so it has to be there before. And it should be developed without 
compromises.

Of course it would be helpful to see as many Zope 3 components as 
possible backported to Zope 2. I guess migration will be much smoother 
if people get used to some of the Zope 3 concepts early.

So much for today

Joachim