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

[Joachim Werner]

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?
- Can we build stuff into 2.6 that makes people start thinking the Zope 3
way?
- ...

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

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.

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.

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.

This mainly means that we need an excellent DESIGN (i.e. API) on that level.
Implementations may vary, but the interfaces should be as stable as
possible.

Some suggestions for that kind of design (which seems to be much easier to
accomplish on the Zope 3 platform, which seems to have implemented some of
that stuff already):

- Storage should be completely separate from the data model. It should be
possible to design a content class and then store it either in ZODB, the
file system, an RDBMS or an LDAP server or whatever.

- All the basic API (like "store", "delete", "edit", ...) must be free of
HTTP specifics, so that I can modifiy content either over a web frontend or
over WebDAV, FTP, ... - and even via a "fat client" application like a
wxPython application. Currently that one is a mess.

- On the HTTP end, skinning/chroming should work with ALL components.
Imagine being able to create a design that works with Squishdot, CMF, and
your own stuff out of the box, without having to change the implementation
of the tools that are skinned.

- The security API should really work. Currently there seem to be some
really bad flaws with regard to checking for roles (and local roles). (I can
go into details with that if somebody asks me and I find the time).

- There should be a more rigid development model and tools to implement it.
Currently it is hard for Zope developers to know where the business logic
has to go. DTML really invited people to mix stuff, and ZPT seems a bit
complicated to handle in terms of the actual syntax used. It isn't too
readable either.


Joachim