[Zope3-dev] Zope.org - SteveVisitingFredericksburgSprint

[Jim Fulton]

Martijn Faassen wrote:
> 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. 

Well, I disagree.  I am going to try to start the Zope 2.8 release cycle
in January.  This depends on the MVCC work. As soon as that's done, we'll
do a feature freeze for Zope 2.8.

> 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]

This schedule was driven by a specific funded project to add ZPT I18n
support to Zope 2.  That project was going to add ZPY I18n support
by adding some Zope 3 ionfrastructure.  That project fell through and
ZPT I18n code was ported from the Zope 3 ZPT implementation to the Zope 2
ZPT implementation. As a result, *that* Zope 2.7 plan fell by the wayside.

The Zope 2.7 that we have today has nothing to do with that original plan.

The schedule for Zope 2.7 has largely been driven by the number of
volunteers.

> 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.

As I mentioned a few weeks ago, we are intentionally limiting the scope of
Zope 2.8 so that we can have a shorter release cycle.

> I want to be able to use parts of the component architecture (and 
> later parts of ZCML) in Zope 2.7.

In fact, we (ZC) have been doing this for some time, even with Zope 2.6.

 > 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. 

I couldn't follow the last part of that paragraph.

It's too late to add new features to 2.7.

> 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.

I really don't see that modifying the Python path is a big deal.
In fact, you can specify additional paths easily in 2.7's zope.conf
file.

 > 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 __implements__ 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 __implements__ directly; a 
> programmer doesn't manipulate __implements__ directly but uses functionality 

Actually, Zope 3 interfaces support use of the __implements__ attribute for
backward compatability.

> 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.

IMO mixing old-style and new-style interfaces in the same program is
a recipe for disaster.  It is likely that people will want to extend and
mix existing interfaces. It would be really bad if people had to think hard
about which ones they were dealing with.


> 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..

Ok, I've considered it. I think it's a bad idea.

I'm sorry, but it's just not that hard to change the path.

I'd be willing to consider including Z3 interfaces in 2.8 if people
think that would be very desireable.  I expect Zope 2.8 to be released
no later than February.

> 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..

We've been aboe to use Z3 in Z2 for some time. It's not that hard.  Perhaps
we should write up our experiences with doing so.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org