[Zope-dev] Zope 2.6 planning - call for contributors!

[kapil thangavelu]

On Wednesday 06 March 2002 04:58 am, Joachim Werner wrote:
> Hi!
>
> What I'd expect from Zope 2.6 depends a bit on when Zope 3 will be
> available.
>
> If we are talking about a couple of months, I'd prefer only having bug
> fixes in 2.5.x (and no 2.6 at all). If we are talking about more than half
> a year, or even a year from now, things look different.
>
> The problem is that all time that is invested into Zope 2.6 will be lost
> for Zope 3 development, but on the other hand I can't imagine how I would
> convince a customer to fund Zope 3 development if the results will not be
> useable soon.
>
> So what we actually need is a Zope 2.5.x to 3 migration path and plan that
> justifies investments in either Zope 2.6 or Zope 3. For that, we'll have to
> answer a few questions, like
>
> - Are there any components in the Zope 3 development cycle that can be
> backported to the 2 series? 

personally i would be interested in a backport of the component architecture, 
but i think that focusing development efforts on the zope3 core, is a more 
useful allocation of resources. zope3 will be ready faster the more people 
are willing to work on it. i know that i've been guilty of having not worked 
on it, since i have need to finish developing projects now on zope2 before i 
get to work on it.

that said, i really like some of the proposals on the table for 2.6, but i 
just don't think that backporting zope3 to zope2 is a good use of people's 
time.

> - Can we build stuff into 2.6 that makes people start thinking the Zope 3
> way?
> - ...

in this regard the component architecture would make the most sense... but 
again it would be fairly much a developer resource, and without the 
components, services, and utilities themselves it would just be lookup and 
structure to applications. most of whats in zope3 currently is architecture.

> I don't want Zope to end up like ArsDigita's ACS. They had a perfectly
> working 3 series that had all the features you'd expect, but was butt ugly
> in terms of the actual implementation. Then they started from scratch (like
> Zope is doing now) and built ACS 4, which was well-designed, but buggy as
> hell and had only core functionality. The plugins had not been ported yet.
> Then they started from scratch again and ported to Java (which Zope will
> not do I guess).
>

regarding the acs4

there were many plugins (dude, packages is the preferred nomenclature ;) 
ported to the acs4 architecture. in fact there are more of them then there 
were for the 3x platform (partly in due to improved modularity). that 
platform still lives on and thrives today in the form of the openacs. and 
includes some services and functionality in the core that i hope zope3 will 
bring to zope land (package management, workflow, calendaring/events, etc...)

the move to java and the fall of arsdigita came as direct result of tasting 
too much of that poisoned apple, known as venture capital.

> Currently there are 500 or so freely available Zope add-ons on zope.org,
> which will most probably not work on Zope 3, at least not with the "3X"
> series. And there are even more non-free Zope products people have built on
> the 2 platform.
>
> I have the feeling that many of the add-ons will not be needed for Zope 3
> because Zope 3 will do better out-of-the-box. But for many others there
> must be a migration path.

i don't know how much discussion there has been on this, but its something 
worth discussing in more detail, namely the use of the ZopeLegacy system for 
zope2 products. when things are a little more settled down for zope3, an 
excellent piece of documentation would be a product porting guide.

> Let's take the database adapters. If Zope 3 does not support the major
> databases from the beginning, it might not get the momentum it needs.

completely apriori, i think these will be a fairly easy thing to port ;) .

> Slightly off topic, I think what Zope (2 AND 3) need really urgently is
> another layer on top that delivers what the CMF (IMHO) did promise but not
> deliver to the extent I had expected: A solid foundation for Content
> Management Systems.

just curious, what do you see as the problems with the cmf?

<snip good stuff and removed cross-posting>

cheers

kapil