[Zope3-dev] Zope.org - SteveVisitingFredericksburgSprint

[Martijn Faassen]

Jim Fulton wrote:
> Zope 2.9 will begin the transition to Zope 3 by making some
> features of Zope 3 available in Zope 2.  This sprint will
> map out and begin to integrate these features.

Since I don't expect 2.9 to be out for quite a while and I would
like to use the CA in Zope 2 quite soon, the sprint to work on 
Zope 2.9 in early january doesn't excite me but actually *worries* me.

I'm going to make some assumptions about Zope 2.x release frequency
in the following post. Note that I'm not blaming ZC for releasing
Zope 2.x releases slowly or anything like that. 2.7 is taking
a while, but I'm not really bothered by it. Releases are hard and take
a lot of time. The release frequency for Zope 2.x is just fine and I
don't want to go into a debate about the frequency itself; I'll
just assume it as a given. 

I saw you post the following:

"""
We need to get 2.7 and 2.8 out the door as soon as we
can so we can get working on 2.9.
"""

You could therefore claim that I shouldn't be worried and 2.9 will
be released in a few months. I don't think that this is realistic,
and expect 2.9 somewhere in 2005. This is why:

I am assuming it's not possible to increase the release frequency 
drastically. Historically half a year is normal for Zope 2.x
releases. 2.7 has been taking a year and a half so far.

[as an ironic aside note that in the summer of 2002 it was planned to be
the release that would include Zope 3 technologies (what is now expected for 
2.9), and that it was expected to be released in the fall of 2002, or even 
before 2.6.. I never considered this at all realistic so wasn't disappointed
very much when that didn't pan out]

Maybe you can speed up Zope 2.x releases to be half a year again,
which would be impressive as Zope 2.8 and 2.9 are going to have 
large changes which will take a while to settle down. This still means that 
Zope 2.9 final is at least a year off. 2004 if we're being optimistic,
with customer deployments in 2005.

I want to be able to use parts of the component architecture (and 
later parts of ZCML) in Zope 2.7. The first thing I need is interface-based
adapter lookup, and after that parts of the view system. I am not
prepared to wait a year.

My timeframe of starting to use Zope 3 technology in Zope 2 is february,
2004. I want to deploy in mid 2004. I think this is possible, but
not with Zope 2.9, but with 2.7.

I strongly urge a focus on trying to make Zope 3 functionality 
deployable and integratable into Zope 2.7 by installing the right Python
packages. A focus on *not* modifying 2.7 and still offering Zope 3
functionality. Being able to modify Zope 2 to do this doesn't mean that
is actually the right solution for getting Zope 3 technology in the
hands of Zope 2 developers. 

As an example of what I think is hard is deploy and a non-optimal strategy
is Jim's wrapper interface module making Zope 3 interfaces work with Zope 2. 
It has to be installed by manipulating the PYTHONPATH. It'd be only easy to
deploy once it's included in the Zope 2 core and heavily tested. This won't
happen in 2.8 I heard, so I'll have to wait until 2.9. As I said before,
I'm not gonna.

All this actually not necessary. You can use Zope 3 interfaces in Zope 2
well without all this right now, except for one problem: there is a name clash
as Zope 2 tries to use __interfaces__ as an attribute and Zope 3 interfaces 
also uses this same attribute. Zope 2 fails when it finds a Zope 3 interface in
in this attribute.

Now Zope 3 interfaces actually don't rely on __interfaces__ directly; a 
programmer doesn't manipulate __interfaces__ directly but uses functionality 
like 'implements()'. It's therefore possible to call this something else, like 
__interfaces2__, and have everything work. Zope 2 interfaces stay what they 
were, you ignore them when you write Zope 3 style code in Zope 2 and use 
Zope 3 interfaces instead.

This can be deployed far more easily -- no PYTHONPATH manipulation necessary
before you start Zope 2. Far less possibility for bugs or other problems than
if you try to make Zope 3 interfaces work like ones in Zope 2.
The only thing necessary is the need to rename __interfaces__ in the 
zope.interface package, which should be automatable even.

With this strategy interfaces for classes seem to work just fine and I can't 
see any migration problems later either. For per-object interfaces you 
introduce a data migration problem if you want to migrate Zope 2 objects 
directly to Zope 3. But:

  * that's not going to happen any time soon.

  * it's the least of the problems when you do such data migration.

Please, please, this strategy of getting Zope 3 tech into user's hands
into serious consideration if you haven't already..

Jim, you have the power to change Zope 2 all around in order to support
Zope 3. That doesn't mean that this is actually the best approach to get
some Zope 3 technology in Zope 2 users' hands within a reasonable timeframe.
 
I can't make it to this sprint, but if your solution is going to sit off
in some CVS branch somewhere for a year or more and isn't useful and
deployable in Zope 2.7 then I'll be forced to have to duplicate some
of your work, as I'll be focusing on my own strategy of making Zope 3 
technology work in Zope 2.7. I'd prefer working together with you instead.

I'm sure what I'll come up with will be less powerful than what you
are planning for Zope 2.9 and be able to do far less with it. But the
gain is that customer deployments of Zope 2+3 technology could happen
at least half a year earlier..

Regards,

Martijn