[Zope-dev] direction

[Hanno Schlichting]

On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida
<leorochael at gmail.com> wrote:
> I noticed you've been very busy doing clean-up on the Zope2 code base
> in the last few hours. As someone who has recently spent a lot of time
> porting forward a large and mission-critical code base, ERP5, from
> Zope 2.8 to Zope 2.12, I'm a little confused about the direction that
> you're moving, and how much effort that could mean for future porting
> efforts for Nexedi.

I think moving to Zope 2.12 and 2.13 does have some value for Nexedi
or other large existing codebases, as you get support for current
versions of the ZODB, Zope Toolkit packages and support for Python 2.7
with Zope 2.13. Since Python 2.7 is a long-term maintenance release
for Python itself, this should provide a stable and good basis for the
next years - the statements from the Python community aren't
completely clear - but I'd expect to see ongoing maintenance until
2013 or maybe even 2015.

Going forward I can see two paths for Zope 2. Either we don't touch it
at all anymore and let it bitrot or we try to move it forward and
adept it to current best practices of development. Since complete
rewrites almost always fail, like we have seen with Zope 3 - I prefer
changing Zope 2.

If you are interested in stability I think sticking with an "older"
version of Zope 2 is a completely sane and good approach. What me and
others from the Plone community are trying to do with the Zope 2
codebase is to actually move it forward. We can either do that as part
of the official Zope 2 release series or fork the codebase. Since so
far there isn't really anyone else interested in working on the Zope 2
codebase, we keep changing Zope 2 without forking it.

> But can you explain to us a little of how you expect Zope2 to behave
> with the changes you're doing?

There's a number of things I want to do. Not sure when I'll or others
will have the time, but these are things I expect to happen in the
next months or releases:

- Continue to remove functionality tailored for TTW development, like
SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
- Document and use the WSGI publisher and remove obsoleted
functionality like the virtual host monster, error_log,
ZServer/medusa, zopectl/zdaemon
- Make the browser id manager, session data manager, temporary storage
optional and remove it and request.SESSION from the core, instead we
can use something based on Products.BeakerSessionDataManager /
collective.beaker if someone has a need for sessions
- Start using and storing parent pointers and remove
Acquisition.Implicit from the most common base classes (a branch for
this already exists with almost all core tests passing)
- Merge five.pt (Chameleon) into the core and use it instead of the
zope.tal/zope.tales implementation (which means no more
RestrictedPython for templates)
- Once most of the ZMI is gone, it should be feasible to drop DTML or
rewrite what little is left as page templates

I think what's going to stay is AccessControl, OFS (a bit lighter),
ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of
Zope Toolkit libraries like components, events, browser pages and so
on.

That's the kind of scope that should be possible to port to Python 3
and actually modernize enough to be understandable. At that point we
should even be able to catch up with years of missed security updates
- almost nothing in current Zope 2 protects against XSS, CSRF or any
of the other common security risks we have on the web today.

What I'm outlining here has of course almost nothing to do with the
original idea and scope of Zope 2. Maybe at some point this should get
a different name ;-)

I hope this makes the direction of where I am headed clearer or more
generally what Plone expects from its underlying framework.

Hanno